Startup engineering culture when you are the only engineer
For the first four months I was the entire engineering department. No code reviews, no architecture discussions. Here are the practices I invented to stay honest.
For the first four months at FinanceOps, the engineering team was me. One person writing every line of code, reviewing nothing, deploying everything, and making architectural decisions that would constrain the product for years. Nobody to tell me my abstractions were overcomplicated. Nobody to catch the bug I introduced at 11pm. Nobody to argue against the library I chose because it had a cool API but no maintenance activity in six months.
Solo engineering at a startup is not a staffing problem you endure until you can hire. It is a distinct operating mode that requires deliberate practices to avoid drifting into bad habits. I developed five practices during those four months that kept the codebase honest and my judgment calibrated.
What felt like a technical post at the time was usually me learning management in disguise. It also builds on what I learned earlier in “Bootstrapping a Next.js monolith when everyone says microservices.” I was figuring out, in public, that your first engineering culture is just the pile of defaults you create when nobody else is in the room yet.
The Pre-Commit Checklist
Before every commit, I run through a five-question mental checklist. I wrote it on an index card and taped it to my monitor. The questions are designed to catch the specific failure modes of solo development.
- Would this commit message make sense to someone who has never seen this codebase? If not, the change is either too large or too poorly scoped.
- Did I actually test the unhappy path? Solo developers skip negative testing because they know the happy path works and there is nobody to demand edge case coverage.
- Is this abstraction earning its complexity? Without code review pushback, I tend to over-abstract. Every new interface, every generic type, every helper function needs to justify its existence.
- Would I be comfortable if a senior engineer from Stripe read this file? This is my quality bar. Not perfect code, but code that demonstrates professional judgment.
- Can I explain why this approach over the alternatives? If I cannot articulate the tradeoff, I have not thought about it hard enough.
The checklist takes about sixty seconds per commit. In four months it caught eleven changes that I revised before committing. Three of those were genuinely bad architectural decisions that would have been expensive to undo later.
Decision Logs I Argue Both Sides Of
Every significant technical decision gets a one-page decision log. Not a long architecture document. Just a markdown file with four sections: the decision, the alternatives I considered, the tradeoffs of each, and why I chose what I chose. The trick that makes this useful for a solo developer is that I force myself to write a genuine argument for the approach I did not choose.
When I decided to use PostgreSQL over MongoDB, I wrote a real case for MongoDB. Not a strawman. A genuine argument about schema flexibility, faster initial development, and native JSON document storage. Then I wrote the case for PostgreSQL. Having both arguments in writing forced me to confront the tradeoffs honestly instead of just going with my gut feeling and rationalizing afterward.
I have twenty-three decision logs from those first four months. Reading them back now, two decisions were clearly wrong. I chose a library for PDF generation that I replaced three months later, and I initially over-normalized the database schema in a way that made common queries unnecessarily complex. Both mistakes would have been caught by a peer review, but the decision logs at least documented my reasoning so the reversal was informed rather than confused.
The Weekly Embarrassment Audit
Every Friday afternoon, I spend thirty minutes reading through the code I wrote that week as if I were reviewing someone else’s pull request. I open the git log, look at each commit diff, and ask one question: would I be embarrassed if a senior engineer reviewed this?
The embarrassment standard is deliberately harsh. I am not asking if the code works. I am asking if the code demonstrates good judgment. Are the variable names clear? Are the error messages helpful? Are the test assertions checking the right things? Is the file organized in a way that a new team member could navigate?
- Week 3: Found a service file with 400 lines and no clear separation between payment processing logic and HTTP handling. Refactored into three files.
- Week 7: Found three API endpoints that swallowed errors and returned generic 500 responses. Added proper error typing and specific status codes.
- Week 11: Found a database query that did a full table scan on every dashboard load. Added a composite index that reduced the query from 800ms to 12ms.
- Week 14: Found test files that asserted on implementation details instead of behavior. Rewrote them to test the public API contract.
The audit caught meaningful issues every single week. Not because I am a careless developer, but because solo development without review is inherently blind-spotted. You cannot see your own patterns. The Friday audit forces a perspective shift that partially compensates for the absence of a reviewer.
The GPT-4o Shift
When GPT-4o launched in May 2024, I started using it as a code review stand-in. I paste a file or a diff and ask it to review the code with a focus on maintainability and potential bugs. It is not the same as a human reviewer. It does not understand our domain, our conventions, or our deployment constraints. But it catches superficial issues, suggests naming improvements, and occasionally spots logic errors that I overlooked.
The AI review supplements but does not replace the practices above. It is another layer in the defense stack. The pre-commit checklist catches scope issues. The decision logs catch reasoning failures. The Friday audit catches drift. The AI review catches syntax-level patterns. Together, they kept the codebase in a state where our first engineering hire said “this is cleaner than I expected for a solo codebase” on his first day.
That was the pattern of my first months at FinanceOps: I did not have management scar tissue yet, so I earned trust by making technical decisions that stayed boring under pressure. The same bias toward strict defaults still shows up in lifeos and bisen-apps today.
Being the only engineer is not an excuse for skipping engineering discipline. It is the reason you need more discipline, not less. The practices you build alone define the culture your team inherits.