Startup Engineering Playbook

Sixteen months of work, a failed product, and a near-departure from engineering. I used to think software engineering was about writing fancy code and talking to stakeholders. I was wrong.

This took me almost 2 months of hiatus reading books, writing post-mortems, and learning from my past mistakes. Let me share with you what's important in tech startups:

Architecture matters

In previous projects, I ended up with technical debt that was impossible to pay without a major rewrite, and I had either premature or wrong abstractions. In any serious software project that you have to maintain over time, you need to consider using a serious architecture to keep consistency.

With software architecture, I'm not referring to the folder structure where you separate your code by services, controllers, and views. You can separate your code by folders and it can still create cognitive overhead because of god objects and nonexistent abstractions.

Cognitive overhead is avoided by isolating responsibilities. Use cases should do one functionality well, and you should use ports and adapters to make your code like Lego blocks. However, architecture is a medium, not the end. You don't need to follow all clean code standards perfectly; just ensure your team has standards, Quality Assurance (QA), and can adapt to the change of requirements.

Kill scope creep

I learned how to spot scope creep after falling for it several times. Scope creep refers to any features you believe help the product before you've validated your idea well, even if you don't have proof.

Common examples are:

• Search inputs in feeds with less than 100 total users.
• Filters and multiple categories in a social media feed MVP.
• Combining multiple app functionalities in a single one.
• Features that consider paranoid edge cases (multiple timezones, 5 different notification ways).

I've been telling this to other startup founders and entrepreneurs: First, validate your core feature and get users. Later, if users ask for these features, we can add them. Keep your products and ideas simple.

Question everything

Most people have labeled me as a rebel or paranoid. In business, this is a blessing, because when you don't question an idea, you build without a plan and blindly. You're being reactive, not proactive.

Always ask your team:

1. When is the actual deadline for this project?
2. Why is this needed and what do you expect from this functionality?
3. How is this feature helping users?
4. Do we need this feature or are we building it "just in case"?

Also question your architecture choices often:

• Do I need WebSockets here when I can use Server-Sent Events?
• Is Redis needed here or am I thinking about a fictional scenario?
• Why am I doing optimistic updates when I can just make a new API call for an MVP?

Solve your own problems first

I used to hate sending invoices by hand. I automated it using n8n, Google Docs, Gmail API, and JavaScript in a weekend; now it saves me 2 hours monthly. I also built an automation that turns Git history into business results for engineering reports.

Fix problems for yourself before solving them for others. Maybe your next business idea is an app you build for yourself first.

Choose your path

I tried to get into FAANG, chasing money and reputation. That's not what I want right now. I preferred to work with non-technical founders, dive deeper into backend engineering, automation, and the business side.

• It's okay if you want a job in a startup.
• It's okay if you want to get into FAANG.
• It's okay if you want Series C funding.

As long as you're aware of your strengths and weaknesses, you'll make progress.

General Advice

• Give time buffers: If a project is estimated for 3 months, mention it'll be 5.
• Milestones over hours: Greenfield projects should be charged by milestones.
• Root causes: Don't fix the symptom of a problem; fix the root of it.
• Variation: Learn new things outside work to avoid burnout.
• Planning: It's better to spend 1 week planning than 1 year building mindlessly.

Remember, entrepreneurship is the medium, not the end.

---

What's Next?

Thanks for reading! If you found value in this playbook, here are some ways to continue the conversation:

• Connect with me - Let's discuss your startup challenges and solutions
• Explore the code - Check out my open-source contributions and projects

Remember: Failure is data, data is learning, learning is growth.

---