Cross-posted from Indie Hackers
About a year ago I shipped Fizbuz v1. It was built on AWS Lambda, DynamoDB and Auth0. I had discovered a new, but really interesting, open source tool called Architect that made it really easy to spin-up AWS resources and build fast, and for a while I was really productive. And it worked well... for a bit.
Starting Fast
After doing customer discovery and building a prototype on Rails, I had clear backend requirements:
- Serverless architecture
- REST API for simple read/writes
- GraphQL API for complex reads
- APIs & the data layer bootstrapped by GraphQL type definitions
I had never built a web application using Lambda or DynamoDB, so I was in full "learn" mode. I soaked up everything I could about how to build these kinds of applications and ended up building a ton of API and data layer tooling from scratch.
This felt very productive at the time and I was incredibly proud of how slick it was that I could define a new business object in GraphQL and that matching REST API endpoints and data layer CRUD operations would be automatically provisioned with minimal additional work.
Slowing Down
After a furious few months of coding, I shipped v1 of Fizbuz and started onboarding users. As I came in contact with users, I started to collect more and more feedback on how to improve the product.
This is where I started noticing a slow-down in my ability to ship new features. As I would context switch from non-technical tasks (talking to customers, doing discovery, networking, etc) back to the code, I would sometimes have a hard time understanding how the code worked. Since I wasn't using third-party tools for commons tasks like client-side data fetching or API request processing or database interaction, I couldn't rely on documentation or Google to get unstuck.
The issue came into much sharper focus when I would try to onboard other developers for contract work. Since I wasn't using tooling that they were familiar with, too much time was wasted getting them up to speed on how the system worked, rather than spending time on shipping new customer-facing features.
Screeching to a Halt
A few days ago a user alerted me that when they were using Fizbuz, they noticed that the app seemed to be caught in an infinite loop and was making an endless series of HTTP requests to the server. This wasn't visible in the UI, which is why I hadn't noticed, so I dove into the codebase to figure out what was wrong.
It turned out that I had refactored some client-side data fetching code in order to be more compliant with React best practices around Hooks and Exhaustive Deps. I unwittingly broke perfectly good code and created an infinite loop. In this case, the requests were idempotent reads, but next time who knows? What if they had been writes?
Moving Forward
I love making things, I think all developers do. And I'm proud of much of the code I wrote. It solved a real problem for me and did so in an elegant way. But I had to look myself in the mirror and ask myself this:
Do I really care about building tools to layer REST and GraphQL APIs on top of DynamoDB?
I decided that I care more help developers build better networks and find better opportunities, and my engineering cycles for the rest of the year will be spent on building product and features that deliver on this.
I am currently in the process of evaluating stacks that meet my original requirements and talking to developers who have experience with these stacks and are available for contract work. Right now it looks like AWS AppSync, Prisma and Hasura are strong contenders for the backend and data layer.
I'll be writing more about my journey to ship a v2 of Fizbuz, so please feel free to follow along!
If you have any suggestions on a stack I should look at, please feel free to leave a comment.
Top comments (3)
A sobering reflection, thanks for sharing!
As I moved from hands on development to leadership, one of the things I struggled the most with is to explain what you just shared.
Focusing on value is what keep startups alive!!!
Thanks Nico! It seems to be one of those lessons that developers just have to learn the hard way π
Nice I think might be good to keep it simple instead of just getting the latest and greatest. Nevertheless awesome reflection :)