Full-stack chaos: when the founder, PM, and head of engineering are all you
In a single Tuesday I triaged a database lock, wrote a product spec, pitched an investor, and reviewed a PR. Wearing every hat is a failure mode.
Last Tuesday started at 7am with a PagerDuty alert. A database lock was blocking payment processing. I debugged it in my pajamas, found a long-running analytical query that was holding a row lock on the payments table, killed the query, and wrote a post-incident note. By 9am I was in product mode, writing a spec for the new invoicing module that two clients had requested. At noon I put on a collared shirt for a video call with a potential investor where I presented our product roadmap and unit economics. At 3pm I was back in the code, reviewing a contractor’s pull request against our coding standards. I ate dinner at 9pm.
This is not a flex. This is a failure mode. When one person holds the founder title, the PM title, and the head of engineering title simultaneously, the default outcome is that all three jobs get done poorly. I have been in this mode for seven months and the only reason it has not blown up is because I have developed a deliberately ruthless system for managing my time and decisions.
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 “Hiring our first engineer: the mass-interview process I built as a non-recruiter.” 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 Time-Boxing System
Every day is divided into three blocks. Engineering block runs from 7am to noon. Product and business block runs from noon to 3pm. Operations and communications block runs from 3pm to 6pm. The blocks are non-negotiable unless there is a production incident.
- Engineering block (7-12): Deep focus work. Code, architecture decisions, code review. No meetings, no Slack responses, no email. My phone is on do-not-disturb. This is where the actual product gets built.
- Product block (12-3): Client calls, product specs, feature prioritization, competitor analysis. This is where I decide what to build next and why.
- Operations block (3-6): PR reviews, contractor coordination, investor communications, hiring tasks, legal and compliance conversations. This is where I keep the business running.
The critical rule is that engineering gets the morning. Cognitive research consistently shows that complex problem-solving ability peaks in the first few hours after waking. I refuse to waste that peak on email triage or status meetings. The code gets my best brain, and everything else gets the afternoon.
Decisions I Refuse to Make Quickly
When you are the sole decision-maker, the temptation is to decide everything immediately because there is nobody to consult. Speed is a startup advantage, but speed on the wrong decisions is a startup killer. I maintain a short list of decision types that I refuse to make in under 24 hours, no matter how urgent they feel.
- Database schema changes: A bad schema decision costs weeks to fix. Every migration gets a one-page decision doc with alternatives.
- New external dependencies: Every new library or service adds maintenance burden. I sleep on every new dependency and check the package health the next morning.
- Pricing changes: Price changes affect every existing client relationship. They get 48 hours of deliberation minimum.
- Architectural patterns: When I am tempted to introduce a new pattern (like event sourcing or CQRS), I write the case against it first and revisit the next day.
This list has saved me at least three times. I almost adopted a complex event sourcing pattern for our audit trail at midnight after reading a blog post. The next morning I realized our simple append-only audit table was doing the same job with one-tenth the complexity.
Decisions I Force Myself to Make in Five Minutes
The flip side of slow decisions is that some decisions do not deserve deliberation. Spending an hour choosing between two equivalent libraries is a waste of time. I have a category of decisions that must be made in five minutes or less.
- Code style and formatting choices: Pick one, configure the linter, never revisit.
- Which of two equivalent approaches to implement first: Flip a coin if the tradeoffs are genuinely balanced. The cost of deciding is higher than the cost of being slightly wrong.
- Whether to attend a meeting: If the agenda is unclear, decline. If my input is optional, decline. If it could be an email, request an email.
- Bug priority: If it affects money, it is P0. If it affects user experience, it is P1. Everything else is P2. No further analysis needed.
The five-minute rule sounds reckless but it is actually a discipline against perfectionism. Solo founders burn hours on decisions that do not matter because there is nobody to stop the deliberation. The five-minute timer is that stop.
The Honest Assessment
Seven months of triple-hatting has taught me that the three-role model is unsustainable past the first year. The engineering work suffers most because it requires the deepest focus and gets interrupted the most. Product decisions suffer second because there is nobody to challenge my assumptions. The business operations work is ironically the easiest to maintain because most of it has natural external deadlines that force completion.
The hiring plan is clear: the first hire was an engineer to share the engineering load. The second hire will be a part-time product person to challenge my product assumptions. I will hold the business operations hat the longest because that is the founder-specific work that does not delegate well until the team is larger.
The builder phase was less glamorous than people imagine. It was mostly a series of stubborn, unfashionable choices that kept future-me out of 2 a.m. incident calls. I still make the same kind of choices inside lifeos and bisen-apps.
Wearing every hat is not a badge of honor. It is a temporary operating mode that you should be actively working to exit. The goal is not to do everything. The goal is to build a team where everyone does one thing well.