Elaborating on Pre-coherence startup infrastructure
This is an elaboration on some thoughts in my other post about Pre-coherence startup infrastructure. Which was originally posted in a deepfates tweet thread
In a pre-coherence startup environment, you have no product-market fit or even any understanding of what you're actually going to end up building.
When you live in that environment, it's important to prioritize experimentation, exploration, and learning because everything you do informs the forks you follow as the path unfolds.
That means you need shared team infrastructure that makes mistakes cheap/free and gives people a boost when they try new things.
--
Pragmatically speaking, in my experience, a lot of this looks like table-stakes engineering infrastructure:
1. Pull Requests + CI + CD + deploy/build/ship on merge to main
This encourages incremental atomic commits/feature branch development, which in turn speeds up time to recovery and debugging (make mistakes cheap!)
2. Basic utility services
Let's say you have a 10-person engineering team working on some LLM wrapper app. Every person on the team frequently makes API calls to 3 different LLM API providers.
By default, that means that each engineer must manually navigate how to acquire API keys and set up their local environment.
10 engineers, hundreds of clicks, and 30 new API secrets floating around in the wild.
There's a downstream security risk in all of the secrets and unforeseen complexity in each engineer's development environment (like typos and minor breakages). This hidden shit adds up and bites you in the ass as you grow.
A better solution here is to make a single LLM proxy service for your team, and then everyone can operate without needing to acquire 3 secrets and configure yet another thing in their development environment.
It takes an hour to build and saves large amounts of intangible complexity.
Also, dev tooling: set up sentry for exception tracking, and set up llm observability tooling make it possible to trace/debug errors as they happen.
3. Shared artifacts
It's important that everyone on the team has their hands on sculpting the SAME shared artifact.
When everyone contributes to the same thing, the cost of staying in sync decreases, and the ease of collaboration increases.
It's important to all be on the same page and not working in different directions. If you have different subteams working on different parts of the app, make sure they're integrating their work together. Otherwise, you're just driving a wedge in the collaboration and potential of the team.
Shared artifacts have a second-order multiplier on top of the basic utility services mentioned above. You turn on one new API or feature, and suddenly, all 10 engineers (plus all future hires) get a boost in productivity.
4. Daily standups
Standups are not meetings; they are the bare minimum communications infrastructure to ensure conflicts, resolutions, and PSAs are communicated to consensus.
Also, bare-minimum social time for remote teams. Which is important and hard.
The goal is to build a single shared vision across the team.
5. Basic issue tracking
People hate issue trackers. The sad reality is they enable you to build more ambitious projects.
When you file bugs, track issues and your work; basic collaboration gets much easier. Important information is no longer hidden in one person's notes, it lives in everyone's notes.
In the mid-to-long term, you collaboratively create a shared knowledgebase artifact of the entire history of your company. This is intangible but important for a coherent culture after growth.
My personal preference and interest in all of this is to focus on and play in the #2 area of Basic utility services.
Working on small/simple, load-bearing APIs that save time and create immediate value is incredibly rewarding.
These little load-bearing APIs end up being incredible points of leverage during growth/scaling.