Building the First Version

Treat your first version as an instrument for learning whether one specific person will use one specific thing to get one job done. A small version of the final product is something else, and usually slower to build. Ship it quickly on boring foundations, measure it from the first day, and put in the few safeguards that are expensive to add later.

Scope Small, Ship Fast

Most first versions fail because they try to serve everyone a little. Pick one user you can name, ideally someone you have already talked to, and one job they are trying to get done. If you cannot describe the product as "X helps Y do Z," the scope is not finished yet.

Write down the single path a user takes from arriving to getting value. Build everything on that path well. Cut, fake or do by hand everything off it.

Instagram is the classic case. Kevin Systrom and Mike Krieger spent about a year on Burbn, a location check-in app, including a complete native iPhone version that "felt cluttered, and overrun with features." They stripped it back to photos, comments and likes, rebuilt it in about eight weeks, and launched it as Instagram (2010).

Run each feature on your list through a few questions:

• Does the user need it to complete the core job the first time?
• Would they notice if it were missing, or would only you notice?
• Can you do it manually behind the scenes for the first twenty users?

Settings pages, team management, dashboards, billing tiers and integrations are usually the first things to cut. Add them once someone has asked twice.

Time is the main cost of a first version, and it compounds. Every week you build without users is another week of untested assumptions. Set a ship date measured in days or a few weeks, then cut scope to hit it rather than moving the date.

Shipping does not have to mean a public launch. It means a real person outside your team using the product for the real job, and that can be five design partners on a private link. You want contact with reality; attention can wait.

Keep the release loop short after that. If you can deploy many times a day with little risk, you will fix problems while the user who reported them still cares, and the product will improve daily instead of in occasional large releases.

Building With AI Agents

Coding agents have changed how fast a small team can build. They can scaffold an app, write the routine parts of a feature, produce tests, migrate code between libraries and explain an unfamiliar codebase. In Y Combinator's Winter 2025 batch, about a quarter of startups had codebases that were 95% AI-generated.

The speedup varies a great deal, so measure it on your own work. In a 2023 controlled experiment, developers using GitHub Copilot finished a well-defined task 55.8% faster than those without it. But in a 2025 randomized trial on real issues in large, mature codebases, experienced open-source developers took 19% longer with AI tools, while believing afterward that the tools had sped them up by 20%. The same researchers said in February 2026 that developers are likely sped up more by newer tools, but their data is only weak evidence of how much.

Delegate work that is well specified and easy to check:

• Boilerplate, forms, CRUD screens and API wiring
• Tests for behavior you have already described
• Refactors with a clear before and after
• Scripts, data cleanup and one-off tooling
• First drafts of documentation and error messages

Review yourself, line by line, anything where a mistake is costly or silent:

• Authentication, authorization and access checks
• Anything that handles money, credentials or personal data
• Database migrations and deletes
• Code that calls external services with your keys
• New dependencies the agent decided to add

Take that last item seriously. A 2025 study of 576,000 generated code samples found models recommending packages that do not exist, at an average rate of at least 5.2% for commercial models and 21.7% for open-source ones. Attackers can register those invented names. Check that every new package is real, maintained and the one you meant.

Agents sound equally confident when they are wrong, so the review burden shifts from writing code to reading it. In Stack Overflow's 2025 survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration, and more said they distrust the accuracy of AI output (46%) than trust it (33%). Google's 2025 DORA research found AI adoption still linked to less stable software delivery and summed up the finding as AI amplifying what is already there. Without good tests and fast feedback, more code means more breakage.

Keep changes small enough to read in one sitting, run the tests yourself, and make the agent explain any change you do not understand. The architecture is still yours. If you cannot explain how your own system works, you will not be able to fix it at two in the morning.

Choose Boring Infrastructure

Your product's advantage is almost never in its database, hosting or login screen. Use managed, widely adopted services for all three, and spend your attention on the part users pay for. Dan McKinley's essay "Choose Boring Technology" argues that a company gets only a few "innovation tokens," and that tools whose failure modes are already well understood leave more of them for the product.

Layer	Default choice	Build your own only if
Database	Managed Postgres or similar	Your core product is a data system
Hosting	Managed platform with git-based deploys	You have unusual compliance or hardware needs
Auth	An established auth provider or library	You are building an identity product
Payments	An established payment processor	Never at this stage
Email	A transactional email service	Never at this stage

Boring technology now has a second benefit. Coding agents tend to handle popular tools better than obscure ones, because far more public code and documentation exists for them, so a mainstream stack gets you better help from people and machines alike.

Don't build for scale you do not have. One well-structured app with one database will carry you much further than most founders expect, while splitting into many services early adds failure points and slows every change.

Security and Data Basics

Speed does not excuse skipping the handful of things that are hard to undo. A leaked database or a compromised admin account can end a young company, and trust lost early is hard to win back.

The minimum, even for an MVP:

• Keep secrets out of code. Use environment variables or a secrets manager, never commit keys, and rotate anything that leaks. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, and 70% of those leaked in 2022 were still valid. Deleting the commit does not help; rotate the key.
• Check permissions on the server. Every request that reads or changes data should confirm the user is allowed to do it, because a hidden button stops nobody who calls the API directly. Broken access control is first on the OWASP Top 10 for 2025, the standard list of the most serious web application risks.
• Use your auth provider's defaults rather than inventing your own password storage or session handling.
• Back up the database and test a restore at least once. Until you have restored from it, you do not know the backup works.
• Collect only the data you need. Data you do not hold cannot leak.
• Turn on two-factor authentication for every admin, cloud, code hosting and domain account. Microsoft reported in 2019 that it can block over 99.9% of account compromise attacks.
• Keep dependencies updated and enable automated alerts for known vulnerabilities.

Write a short privacy policy that describes what you actually do. If you serve regulated industries or sell to larger companies, expect security questions early, and keep notes on your practices so you can answer them honestly.

Instrument From Day One

You cannot learn from usage you cannot see. Before the first user arrives, decide what "it worked" means and make sure you can measure it.

At minimum, track:

• Activation: did a new user complete the core job once?
• Retention: did they come back and do it again without being asked?
• Drop-off: where in the core path do people stop?
• Errors: what broke, for whom and how often?

Name events after user actions rather than page views, and keep the list short. Add error monitoring alongside analytics so you hear about failures before users email you. Then pair the numbers with conversations. The numbers show where people get stuck; talking to them tells you why. With only a handful of early users, a single call is often worth more than a dashboard.

Rewrite or Keep Going

At some point the first version will feel embarrassing to work in. That alone is not a reason to rewrite. Rewrites take longer than planned and freeze product learning while they happen. Joel Spolsky's 2000 essay "Things You Should Never Do, Part I" explains why: old code looks messy partly because reading code is harder than writing it, and the mess often contains years of bug fixes that a rewrite throws away.

Keep going, and refactor in place, when:

• Users are getting value and the problem is mostly code tidiness
• You can still ship changes in hours or days
• The issues are contained to a few areas you can rebuild one at a time

Consider a rewrite when:

• You have found the real product and it is materially different from what you built
• The foundation makes core features impossible, not just awkward
• Security or data integrity problems are baked into the structure

Even then, prefer replacing one piece at a time while the product stays live. Coding agents make rewrites cheaper to execute, but they cost just as much focus. Ask whether the code is stopping you from learning, and ignore whether it is pretty.