Things we’ve learned in our first 100 PRs

We’re building Qwell, a better way to book medical appointments online. We’re a small team taking on a big problem. If you have any thoughts we’d love to hear from you! Send us a note at “hello at qwell.com”.

We just hit 100 PRs at Qwell! This is a big milestone and the result of months of effort from the team. Even though we’re no where near being done we wanted to take the time to reflect on how things have gone so far.

What we’ve learned.

• Getting a project off the ground takes a lot of time.

Configuring AWS, building a CI/CD pipeline, getting it all behind your domain, etc. takes time that you have to plan for.

• Working with unfamiliar languages under a tight deadline is really hard.

Our stack is React + Node. We’ve each worked in both of those technologies before but they weren’t our core competences. With all the other things we had to figure out, learning a new tech stack didn’t have to be one of them.

• Sophisticated infrastructure without the need leads to headaches.

Our infrastructure is built to be highly scalable! The problem is we only have a handful of production users. We could’ve saved a tremendous amount of time waiting to solve the scaling problem for when it actually becomes a problem.

• Spending the time upfront to understand limitations of 3rd party services that are core to your business will pay off in the end.

We use a handful of 3rd party services to run key parts of our business. This can be a huge time-saver unless you fail to understand its limitations until deep in its implementation at which point it’s a huge time-waster. Spend some time upfront to do technical due diligence.

• An unsustainable work pace is unsustainable.

Facing an overflowing backlog of features to build, some people’s (my) natural approach is to work crazy hours. Study after study after study show this doesn’t work.

• Ignoring stressful activities will only cause more stress.

I’ve found time-boxing myself, to say 30 minutes, is a great way to approach anxiety-inducing activities. I bet you, like us, will find you’ve overestimated the effort required!

• Reach out for help sooner rather than later.

At some point we all run into problems we just can’t figure out. We’ve spent too much time in our own minds trying to figure them out. Use your coworkers! Use free “expert resources”, if available (like the AWS Pop Up Loft)!

• Work in Progress is faster initially but will slow development to a crawl eventually.

See Demo-Driven Development leads to Work in Progress.

• Demo-Driven Development leads to Work in Progress.

We had good intentions, demo to users sooner rather than later. In practice we were building features that were “demo-able” not “done”, a slight distinction that can become dramatic if your users aren’t technical.

• End the day at a reasonable time.

See An unsustainable work pace is unsustainable.

• Set up error reporting early.

We spent too much time doing things that an error reporting service could’ve done for us. We use Sentry and it’s great. This should be done on Day 1.

• Set up linters early.

Spending any time thinking about code style is a waste of time and energy. We only recently set this up and it could’ve saved us time & frustration. We’re fans of Prettier. This should also be done on Day 1.

• Celebrate wins, no matter how small.

The grind of building a company is real and it’s easy to forget to stop and look at what you’ve done. If we could do it over again we would’ve done this from the start.

• Respect the Prime Directive.

The Prime Directive states: “Regardless of what we discover, we understand and truly believe that everyone did they best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” I now understand what this means.

• Product discovery should be continuous.

Software requirements change rapidly. We only spent a week up-front to do product discovery and that wasn’t enough (and yet too much). Our target audience changed soon afterwards and so did our requirements. Making sure you’re Building The Right Thing is a never-ending process.

• Build the simplest possible solution first, preferably without writing Software.

Writing Software is hard and expensive. You probably don’t need to automate that thing on Day 1. Do the things that don’t scale first. We didn’t and ended up spending time on features that didn’t ultimately matter.

• Take the time to maintain a project-management tracker.

When working on a small team it’s easy to be okay with everyone having only a mental model of the project, that’s how we operated for a bit. It’s fine until there is ambiguity and there will always be ambiguity. Project-management tools have value today and in the future (why did we build that thing again?), it’s worth maintaining from Day 1.

• The best software is software that works.

I’m proud of the fact that we have software that works and serves our customers. That’s what utimately matters.

Outtro

We’ve failed a lot over the first few months and we’ll fail in the months ahead, but that’s okay because we’ll keep learning! If you’d like to get in touch or just say hi send us a note at “hello @ qwell.com”!