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 morterms 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 paid 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 meaning 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 isolating responsibilities. Use cases do one functionality well and you 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 you 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 (but you can find everything in a single page...)

• Filters and multiple categories in a social media feed MVP (are the people even posting there?)

• Combining multiple app functionalities in a single one (is this a social media app, a habits tracker or what?)

• Features that consider paranoid edge cases (let's add multiple timezones because of... let's send the user a message in 5 different ways...)

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

Something else happens when you don't cut off scope creep:

Your product gets more complex to use and your users stop using the app.

This note itself has its worth in gold. Keep your products and ideas simple, add new features and functionalities only when other people ask for it.

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 make sure to ask these questions to your team:

• When is the actual deadline for this project? (always be asking this, it might sound relevant but PMs and non-technical people change their minds quite often)

• Why is this needed and what do you expect from this project or functionality?

• How is this feature helping users and why is it important?

• How are we different from the competition and why is people going to use our products?

• Do we need this feature or are we building it just in case?

Also question your architecture choices often:

• Do I need to add Websockets here when I can use server sent events?

• Is Redis needed here or am I just thinking about a fictional scenario?

• Am I normalizing my schemas for the sake of it or is this helping the business?

• Why am I even doing optimistic updates when I can just make a new API call for MVP?

Solve your own problems first

I used to hate sending invoices because I was doing the whole process by hand.

I automated it using n8n, Google Docs, Gmail API and JavaScript in a weekend, now it saves me 2 hours monthly.

To be honest I also dislike sending weekly engineering reports by hand because it's all on the Git history but someone has to translate it to stakeholders.

So I built another automation. It gets the git history of a repository and turns it into business results. I tweak it and I have a meeting agenda.

These are for my business and they're humble integrations that solved actual problems I had. my message here is simple:

Fix problems for yourself before solving them for others

How can you guide and support other people if you're not able to support yourself first? You need to be willing to learn from your mistakes and find ways to improve yourself.

Maybe your next business idea is an app you build for yourself first.

Think about it :)

Choose your path

I tried to get into FAANG and I was chasing it, but for what really? Money and reputation? That's not what I want right now.

I promised myself I was not going to compete with other engineers to land a fancy job.

I've preferred to work with non-technical founders, dive deeper into backend engineering, automation and the business side of things. So far, it's worked well and we've shipped great software.

To some people I'm a mentor, for others a founding engineer, and some people don't even know what I do.

This is what I do. I help founders build startups, digital products and I educate others about software engineering and architecture.

It's okay if you want to land a job in a startup.

It's okay if you want to get into FAANG.

It's okay if you want Series C funding.

It's okay if you want to build an app and share it with other people.

As long as you're aware of your strengths, weaknesses, personality traits and understand there won't be an easy path, you'll make progress in your journey.

General Advice

• Give time buffers. If a project is estimated to take you 3 months, explicitly mention it'll be 5 months. You don't know what might change or how life develops.

• If you're consulting, greenfield projects are charged by milestones, not by the hour. It's more beneficial for you and your employer.

• Surround yourself with great people who are willing to improve daily.

• Don't take failure personally, study why things failed, learn to never do so again and move on.

• Don't fix the symptom of a problem, fix the root of it. This applies to everything in life.

• Learn new things outside work, read and experiment with new technologies. Your main position or gig can burn you out if you don't introduce variation in your life.

• Always be willing to have tough talks with your people. Be clear and honest about your perspective and long term thinking.

• Make your codebase and configuration as flexible as possible in startups, your mental health will thank you.

• Your goal as an entrepreneur is to help more people.

• It's better to spend 1 week planning than 1 year building mindlessly.

• Remember, entrepeneurship is the medium, not the end.

---

Thanks for reading! I hope you've learned something new here. You can also learn more about my projects in my website: https://www.itsfranciscoluna.com/