What to Put in Version One of Your App: Hobart Founders

You have the idea written down, a spreadsheet full of features, and quotes from two studios that differ by more than the price of a car. You are not an engineer, you cannot judge which features are hard and which are easy, and you are scared of paying for six months of work only to find nobody wants it.

That fear is correct. Most first versions fail, and they usually fail for the same reason: they contain too much. This post is about how to cut the list down so version one is small enough to ship, cheap enough to survive, and still something a customer will pay for.

Short answer: Version one should contain the one painful job your customer already pays to have done badly, done end to end, plus sign-up and payment. Everything else waits. If a feature does not change whether someone hands over money, it does not belong in v1. A focused first version typically ships in weeks, not quarters, and gives you real users to learn from.

What is version one actually for?

Version one is not the product you pictured. It is the experiment that finds out whether the product you pictured is worth building. Its only two jobs are to put the core workflow in front of a real customer and to let them pay you for it.

A coaching platform founder in Hobart we can use as a running example: she trains career changers, her sessions run off a spreadsheet and a payment link, and she wants an app. Her imagined product has video hosting, community forums, gamified streaks, a mobile app and an admin dashboard.

Her customers' actual pain is simpler. They sign up, they forget what to do between sessions, and they fall behind. The one painful job is: give each client their program, track what they completed, and remind them before they drift. That is the whole product for now. The forums can wait a year.

How do you decide what stays and what waits?

Use one test: would version one still be worth paying for if we cut this? If the answer is yes, cut it. What usually survives that test is short.

Belongs in version one	Waits for version two
Sign-up and login	Profiles, avatars, follower counts
The core workflow, end to end	Settings screens and preferences
Taking payment (or the booking that leads to it)	Multiple payment options and plans
The minimum admin view so you can see what is happening	Dashboards, charts, exports
Email receipts and password reset	In-app notifications, mobile app
Basic privacy and backups	Integrations with every tool you can name

A good rule of thumb: if a feature list fills more than one page, it is still a daydream, not a scope. A real version one for a small product is often five to eight screens. If your quotes assume months of work for a first release, either the scope is too big or the estimate is padded, and you should ask which.

How do you scope it before you talk to anyone?

You do not need to write a technical document, and you should not pay someone to write one for you. Write four things in plain words, one page total:

1. Who uses it. Not "small businesses". One person with a name and a job: "a career changer, 34, paying for weekly coaching, checks email on her phone at lunch."
2. The one painful job. One sentence. "My clients forget their program between sessions and quit."
3. The core workflow. Numbered steps from the user's side: sign up, pay, get my program, tick off this week, get a reminder. If you cannot number it in under ten steps, it is not one workflow yet.
4. What "done" means. Something checkable: "a new client can sign up, pay and see their program without me sending anything by hand."

This page is your brief. Any studio worth hiring can quote from it, and you can check their quote against it: every feature they priced should trace back to a line on your page. Anything else is scope creep arriving early.

Fixed price or hourly for a first version?

For a non-technical founder, fixed price wins more often than not, because it moves the risk of an overrun from you to the studio. With hourly billing, every guess the developer got wrong becomes your invoice. With a fixed price, they carry it.

The honest catch: a fixed price only protects you when the scope is written down and changes are handled explicitly. Ask any studio you talk to how a change request works. "We will just do it" is a red flag in both directions, generous or sloppy. There is a fuller comparison in our post on fixed price versus hourly software development, and Rootech quotes a fixed price for version one after reviewing the idea, so the quote covers what was actually agreed.

What should you ask a studio before signing?

Before you sign anything, ask these. The answers matter more than the price.

1. Who owns the code when we are done? The answer should be: you do, including the repository, the hosting account, the database and the domain, all in your name. More on this in who owns the code when you pay a developer.
2. What happens after launch when something breaks? Bug fixes on what they built should be included for some period, with monitoring and updates after that on a retainer you can cancel.
3. How will I see progress? You want a live URL you can click around in during the build, not a demo at the end. If you cannot test it as it goes, you find out what they misunderstood at the worst moment.
4. What is not included? A quote that says what is excluded is more trustworthy than one that implies everything.
5. What would you cut from my scope? A good studio trims your version one further. A studio that agrees with every feature is selling you the daydream.

What happens after version one launches?

Version one ships, and then the real product development starts, driven by what users do rather than what you imagined. Some of what you cut turns out to be unnecessary forever. Some becomes urgent. Expect the first weeks after launch to be about fixes, small adjustments and watching where people get stuck.

Two things to have in place from day one: monitoring (so you know it is down before a customer tells you) and backups you have actually tested restoring. Hosting for a small product usually costs under $50 a month; AI features, if you use them, typically add $20 to $200 a month depending on volume. If your studio offers maintenance on a cancellable monthly retainer, that is usually cheaper and safer than hiring your first developer too early.

Can I build version one myself with an AI app builder?

Sometimes, yes. Tools like Lovable, Bolt and Replit are genuinely good at getting an idea in front of people fast, and if you are still testing whether anyone wants this, a prototype may be the cheapest way to find out.

The line to watch is real users, payments and private data. Once people are paying and their records live in the app, the shortcuts a prototype takes become risks worth fixing properly, and that is the point to bring in a developer. We wrote a whole post on what to do when a vibe-coded app has paying users. If you are in that position now, our vibe-code cleanup service rebuilds the foundation underneath while the screens your users know stay the same.

The same lesson applies when you hire: build on a live URL, test as it goes, and the prototype-vs-production gap stays small. That is how we run product development for founders, fixed price, quoted up front, and we have done it for products like Sprout Lessons, an AI lesson creator for teachers built from a founder's idea to a live product.

The takeaway

Cut your feature list until it hurts, write your one-page brief, get a fixed price against it, and keep ownership of everything. Version one is a question you are asking the market, not a monument, so build the smallest thing that can ask it.

If you are a founder in Hobart or anywhere in Australia and you want a second pair of eyes on your scope before you sign anything, book a free call and we will walk through your version one list together, send us what you built or what you are planning. We are a Melbourne studio working Australia-wide, and most first versions we build ship in two to four weeks.

Frequently asked questions

How much does version one cost?

It depends almost entirely on scope, which is why cutting features is the best cost control you have. Rootech quotes a fixed price after reviewing your idea, so you know the number before work starts. Expect running costs of under $50 a month for hosting, plus AI usage if your product uses it.

How long does a first version take?

Most builds Rootech does ship in two to four weeks. Bigger platforms get a fixed timeline agreed up front. If a quote for a small version one runs to many months, ask what is in it, because the answer is usually too much scope.

Do I own the code?

You should, and at Rootech you do: the code, the hosting, the database, the domain and every account stay in your name, with a handover of documentation and credentials at launch. Never sign with a studio that keeps this vague.

Can I change my mind about features mid-build?

On a fixed-price build, changes are handled explicitly: new features get scoped and quoted separately rather than silently inflating the bill. That is one reason the written scope matters more than the price on the quote.

What if version one flops?

Then you have learned that cheaply, which is the point. A small version one that flops costs a fraction of a large one that flops, and you own everything you built, so pivoting means changing direction, not starting from zero.