The first year of being a technical startup cofounder

Last year, I wrote a reflection on the first 90 days as a technical cofounder about the first three months of building Craftwork. That article was largely a reflection on the differences between building a company from scratch in 2023 versus the last time I did it, around 2016. Plenty has changed since then, and I think that article is still worth a read.

Today, I want to reflect on the first year of building Craftwork. We've written many chapters of our story in the last year, and I think it's worth taking a moment to reflect on what we've accomplished and what we've learned.

Thank you for sponsoring

Their tech, Their products.... Their Stories.

Code Story is a podcast featuring founders, tech leaders, CTOs, CEOs, and software architects, reflecting on their human stories in creating world changing, disruptive digital products.

Subscribe Today

I've spent a good deal of my career working in UX. I've gotten to work with some incredibly talented designers and UX researchers, and I do believe that good design is a competitive advantage. Even still, when building real features for real people, you can't always predict what will work and what won't.

Designing great software needs to be both proactive and reactive - you need to have a vision for what you want to build, but you also need to actively respond to feedback and data.

For example: the very first version of Craftwork's estimate builder was designed to be extremely self-serve - we built a tool that would let customers scope out their entire project without needing to talk to us. We thought this would be a great way to let people get a feel for what we could do for them, and to be extremely transparent about what their project would cost.

In practice, we found that people were often overwhelmed by the number of choices they had to make. Over and over we saw people getting stuck playing with our estimate builder, weighing the cost of one little change against another. Many people got stuck on this process, and never actually submitted a request for painting.

On a hunch, we ran a quick A/B test to see if it would be more productive to have a conversation with one of our team members first, and the results were clear: our customers have lots of interesting questions, and a price calculator wasn't answering all of them.

We've since reworked the estimate process to be more of a guided conversation, and we've found that using it to create a human connection with our customers has been a great way to build trust and to get the ball rolling on a project.

While building my last company, I was convinced that we could do everything with an exceptionally small team - we were just 3 people, from inception to acquisition. I'm proud to say we did the damn thing, but it was really difficult. You'll often hear founding employees at startups talk about how they're "wearing many hats" - that's definitely true, and it makes work a lot of fun. It's also true that you can't wear all the hats. It's also also true that there exciting, beautiful new hats out there that you don't know you need to wear.

From my first day as a working professional, I've always wanted to be surrounded by people who are smarter than me. Building Craftwork has been no exception - my cofounders are dedicated, talented, and damn good at what they do. We have also hired some truly amazing people to build our team.

Engineers tend to undervalue the importance of understanding the mechanics of the business. Our growth team at Craftwork has been instrumental in helping us understand how to reach new customers, and how to build a profitable product that people want.

Building a brand is like nurturing a garden. It takes time, patience, and a lot of care. Craftwork's brand has really grown into something special, and it's been a joy to watch it happen. Give our Instagram a peek if you want to see what I mean.

At this stage in the startup journey, hiring engineers is really challenging. The perfect engineer for a startup is someone who is comfortable with a lot of ambiguity, who can work independently, and who can communicate well... in addition to being technically competent. It's a tall order, and it can be a challenge to find the right people.

When I have roles open on my team, hiring is the most important thing I do day to day. It is also a full-time job in itself. It requires a fair deal of patience to assemble the right team, as well as a drive to actively and creatively seek out the right people.

I recently came across the Japanese Phrase ほどほど (hodohodo), which means "just enough." I've been trying to use it as a reminder to keep things simple, and to avoid overcomplicating things. My team is tasked with building the features we need most today, with eyes on what we'll need in 6 months and a year... and that can be overwhelming. It's easy to spiral out of control with feature creep and over-engineering, and finding ways to help each other just-enough-for-now is a team remit.

Just enough spills over into many areas:

• Build vs buy: almost every feature our team needs can be bought from a SaaS vendor, or coach built by our product team. Making this decision can be nuanced and difficult, and it's something we revisit regularly.
• Adopting tooling: Engineers love to play with new tools - there's always a new framework, language, database, or library to poke around with. We've been very deliberate about what we adopt, and we've been very careful to avoid adopting things just because they're new and shiny. We have also adopted tools with good intentions, and found ourselves jettisoning them when they don't work out for one reason or another.
• Shipping new features: Adding new functionality for our customers and teammates is always tempting, but it's important to be mindful of the complexity that comes with each new feature. Our engineering team is small-and-mighty, and ever new feature we build means we have less time to support the features we've already built.

I used to say Just enough (and nothing more) - there's a funny irony in that phrase. A year into this thing, this feels more accurate: Just enough (and nothing more).

If you're inerested in a more detailed look at the past year, here's a few more links you might find interesting:

• 🎙️ My interview on the podcast CodeStory was released today. Codestory's creator, Noah, was kind enough to reach out about sponsoring this newsletter as well. Telling Craftwork's origin story is a good reminder of how far we've come in a year.
• 🥽 Learning is an infinite game tells a little bit about how we used 3D printing tech to produce tooling for large-scale paint projects, and what it was like to dive in to CAD modeling after years away.
• 📋 Hiring is hard. There have also been a ton of layoffs in the past year-and-change. I wrote Your Resume Sucks. Here's how to fix it in an effort to help engineers represent themselves better when looking for a job.

I'm grateful for the opportunity to reflect on the past year, and I'm grateful for the opportunity to share it with you. If you have any questions about what it's like to build a startup, I'd love to hear from you. Reply to this email and let me know what's on your mind.