What to Build Before You Write Product Code
Most startup advice focuses on building faster.
Ship faster. Launch faster. Iterate faster.
For a long time, I followed the same advice.
Every new idea immediately became a repository. The first task was always the same: build the product.
The problem was that the product was rarely the thing slowing us down.
The real friction appeared later.
A broken deployment process. Missing monitoring. No transactional email setup. No way to handle user authentication. No analytics. No documentation. No system for managing operational knowledge.
The product worked.
The company around the product didn’t.
After repeating the same mistakes across multiple projects, I started approaching new products differently.
Before writing product code, I now build a small layer of infrastructure around the product itself.
Not because infrastructure is exciting.
Because it removes hundreds of small decisions later.
Quick Answer
Before writing product code, I try to have these foundations in place:
- Domain and DNS management
- Authentication strategy
- Transactional email provider
- Analytics
- Monitoring and error tracking
- Deployment pipeline
- Documentation and knowledge base
- Consent and privacy compliance
- Backup strategy
None of these create customer value directly.
But all of them create leverage.
The Hidden Cost of Starting With Features
Many early-stage products begin with a simple assumption:
We’ll figure out the infrastructure later.
Sometimes that works.
Most of the time, “later” arrives much sooner than expected.
The first customer asks why password reset emails aren’t arriving.
An API starts returning errors but nobody notices.
A deployment breaks production.
A compliance request arrives from a European customer.
The product is still small, but operational complexity has already started growing.
Infrastructure debt appears much earlier than most founders expect.
1. Domain and Identity
The first thing I secure is ownership.
A proper domain.
Company email accounts.
DNS managed in one place.
Clear ownership of services.
It sounds obvious, but many projects start with personal email addresses, temporary domains, or services registered under individual accounts.
Cleaning this up later is always painful.
2. Authentication
Authentication becomes important the moment the first user arrives.
Building auth internally is rarely worth it for small teams.
Password resets, email verification, session management, multi-factor authentication, social logins, account recovery — these are solved problems.
The goal is not to reinvent them.
The goal is to integrate them reliably.
Today, I prefer starting with a managed authentication provider and focusing engineering effort elsewhere.
3. Transactional Email
Users expect emails to work.
Password resets.
Invitations.
Notifications.
Verification links.
If these fail, trust disappears quickly.
Email is one of those systems nobody notices when it’s working and everybody notices when it isn’t.
I try to configure a dedicated provider before the product launches, even if only a handful of emails exist initially.
4. Monitoring Before Traffic
A surprising number of products launch before any monitoring exists.
Then something breaks.
Nobody knows.
Monitoring should arrive before customers.
Not after.
At minimum, I want:
- Error tracking
- Uptime monitoring
- Basic system metrics
- Alerting
The first alert should not come from a customer.
5. A Deployment Process That Doesn’t Require Luck
One of the biggest improvements I made over the years was treating deployment as a product feature.
If shipping changes feels stressful, something is wrong.
A deployment should be boring.
Predictable.
Repeatable.
Ideally, a single command or automated pipeline should move code from development to production.
The less human intervention required, the better.
6. Documentation Earlier Than Feels Necessary
Most teams start documentation after they need it.
I prefer starting before.
Not because documentation is enjoyable.
Because memory is unreliable.
Every decision feels obvious today.
Six months later, nobody remembers why it was made.
A simple knowledge base saves enormous amounts of time.
Especially for small teams.
7. Privacy and Consent
Privacy requirements tend to appear unexpectedly.
A customer asks about GDPR.
A partner requests compliance documentation.
An analytics implementation requires consent management.
Many teams treat privacy as a future problem.
In practice, privacy becomes much easier when considered early.
The goal isn’t to become a compliance expert.
The goal is to avoid rebuilding fundamental systems later.
8. Backups
Nothing feels more unnecessary than backups right before you need them.
And nothing feels more important afterward.
Every product eventually stores something valuable.
User data.
Content.
Configuration.
Operational knowledge.
Backups are cheap.
Losing data is expensive.
Infrastructure Is a Product Multiplier
Infrastructure rarely makes headlines.
Customers don’t sign up because monitoring exists.
Nobody buys software because backups work.
But these systems create something more valuable than features.
They create confidence.
Confidence to deploy.
Confidence to scale.
Confidence to onboard users without constantly worrying about what might break next.
That’s why I no longer start with product code.
I start with the environment that allows product code to survive.
How We Approach This at Nuvo Code
At Nuvo Code, we try to standardize as much of this foundation as possible.
Not because every project is the same.
Because every project benefits from the same operational basics.
Authentication, monitoring, deployment, privacy, analytics, and knowledge management are treated as platform concerns rather than product-specific concerns.
This allows us to spend more time solving unique problems and less time rebuilding the same infrastructure repeatedly.
The goal isn’t perfect infrastructure.
The goal is reducing friction so product development can move faster later.
Ironically, spending time on infrastructure first is often what allows a team to ship products faster in the long run.