Before you build anything
Write down what the product is. A page or two is enough to start:
- who uses it, and what each kind of user needs to do;
- the one thing it must do well in version one;
- what version one deliberately leaves out.
This document decides more than any technology choice. Without it, every option below gets slower and more expensive.
Then talk to the people you think will use it. Eric Ries defines a minimum viable product as the version that gets you the most validated learning about customers for the least effort. Sometimes that is a landing page or a conversation, not an app.
Option 1: build it yourself with an AI app builder
Tools like Lovable, Bolt and Replit can produce a working first draft from a description in days.
Right when: you want to test an idea before spending real money, and you can steer the tool through many small changes.
Watch for: these tools are good at what you can see and weaker at what you can't. Before real users, payments or private data arrive, have an engineer check who can read which data, where your secret keys are and what happens when a payment fails. In 2025 a critical vulnerability was published for Lovable-generated apps whose database rules let unauthenticated visitors read data. Lovable has since added built-in security scans, but it still recommends a professional review for sensitive data.
Option 2: hire freelancers
Right when: you can write the specification, judge the quality of the work and manage people. A freelancer is usually cheaper than a studio.
Watch for: scoping, design decisions and quality control all land on you. If the freelancer leaves halfway, much of the knowledge leaves with them. Protect yourself by keeping the code in your own repository and asking for short written notes on how things work.
Option 3: hire a studio
Right when: you need something real to show investors or users soon, have no technical team and want one team to scope, design and build.
Watch for: studios that keep your code in their accounts, show progress only in reports, or build something only they can maintain.
What to insist on, whichever you choose
- Ownership. The repository, hosting, domains and service accounts are in your company's name from day one. The contract assigns the intellectual property to you in writing.
- Working software, often. You should be able to click something new every week once building starts.
- A specification. Written so that a different team could quote from it.
- Handover. Documentation and a walkthrough, so the next engineer, perhaps your future technical co-founder, can take over.
Still looking for a technical co-founder?
Keep looking while you build. Y Combinator's free Co-Founder Matching platform is one place to start. A working first version, built to be handed over, often makes that search easier: it shows a candidate that the idea has momentum and gives them something concrete to judge.