Web apps & MVPs

Web app development that gets a working v1 into people's hands

If your idea needs people to sign in, keep their own data, pay you, or check a dashboard, a brochure website won't do it — you need a web app. We build MVPs and internal tools for Australian founders and business owners, and the written scope you sign off on is the same document the quote is priced against. This page covers how we keep a first version small enough to launch, and what happens once it's live.

Book a free 30-minute consultationSee pricing

Do you need a web app, or just a website?

A website tells people about your business. A web app does work for them: it remembers who they are, holds their records, takes their money, and shows them where things stand. The moment your idea involves user accounts, a database, payments, or a dashboard, you've crossed from one to the other. Everything on this page is about that second kind of build.

  • Accounts and roles — customers, staff, and admins each see only what they should, with secure sign-in and password resets handled for you.
  • Your own data model — records for jobs, bookings, listings, or invoices, stored in Postgres so they can be searched and reported on later.
  • Payments and subscriptions — one-off charges, recurring plans, or marketplace-style payouts, including what happens when a card fails.
  • Dashboards and reporting — the numbers your team currently pulls out of spreadsheets, updated live and filterable by date, customer, or status.
  • Integrations — syncing with tools you already use, the way Reckonly pushes confirmed receipts into Zoho Books and Inferly sends alerts to Slack.
  • Internal tools — the private admin screens, approval queues, and back-office workflows nobody outside the company will ever see but everyone inside relies on.

How do we stop the scope from growing?

The usual reason a web app project blows out is that the feature list keeps getting longer after the price is set. We prevent that by deciding, before work starts, exactly what version one does and what it deliberately doesn't. That written scope is what the fixed quote covers, and it's what you sign off on. Anything outside it isn't refused — it's quoted separately, so the original budget and launch date stay intact.

  • Discovery ends with a one-page scope: the user types, the screens, the data each screen touches, and the payment or integration points — nothing vaguer than that.
  • Every feature request gets sorted into 'v1', 'after launch', or 'not yet', and the second and third lists are kept in writing so good ideas are parked rather than lost.
  • The quote is fixed against that scope, so if a mid-build request would move the price or the date, you hear about it before we build it, not after.
  • Progress notes each week flag scope drift early, while it's still a conversation rather than a change order.
  • If you genuinely can't decide between two directions, we build the cheaper one to test first — that is the whole point of an MVP.

What does launching a v1 actually involve?

Launch isn't the day the last feature is finished; it's the day real people can use the app without you sitting beside them. We work backwards from that. Early on you get a clickable mock-up to react to, and well before the end you get login details for the real build so you can try each feature as it lands. The final stretch is testing, deployment, and making sure whoever runs the app day to day knows where everything is.

  • A working build is in your hands well before launch — you sign in, click around, and give feedback on the real thing rather than a design file.
  • Testing concentrates on the paths that cost money when they break: sign-up, checkout, password reset, and whatever your core workflow is.
  • Deployment goes to hosting accounts opened in your name, with your domain, SSL, and database backups switched on before go-live.
  • You receive handoff documentation: how to log in as an admin, how to add users, where the data lives, and what to do if something looks wrong.
  • Whoever will run the app day to day gets a short training session, so the first support question isn't 'how do I get in?'

What happens after the app is live?

A v1 that launches is the start, not the end, and we plan for that during the build. The parked feature list from discovery becomes the natural roadmap for a second phase. Whether we do that work or someone else does is entirely your call, because nothing — code, data, hosting, or domain — is registered to us.

  • Phase-two work is quoted the same way as the first phase — a written scope and a fixed price — usually as a Custom Engagement from A$4,500 when it involves integrations or larger features.
  • An optional maintenance plan covers dependency updates, security patches, monitoring, and small fixes so the app doesn't quietly rot.
  • Should a different developer, or your own hire, pick the app up later, the handoff docs and a widely used stack make that a routine handover rather than a rescue job.
  • Day-to-day changes to copy, prices, and settings are designed to be yours to make from the admin area, without a developer involved.
  • You keep every login: hosting, database, domain, payment provider, and the source code repository — nothing is held on our accounts.

Which tools do we build with, and why should you care?

We build web apps in Next.js and TypeScript on top of Postgres, usually through Supabase, and use .NET where a heavier back end is warranted. None of that needs to mean anything to you, and that's the point: these are common, well-documented tools that any experienced developer can pick up. It means you're never locked into us, and it means your app is built with the same tools we use for our own products — Reckonly, Near Space, Inferly, and Scentena.

  • Next.js and TypeScript for the parts users see and click, which keeps the app quick to load and catches whole categories of bugs before they reach you.
  • Postgres for your data, so reports, exports, and future integrations work against a standard database rather than a proprietary store.
  • Supabase for sign-in, file storage, and database hosting, which keeps v1 running costs low and lets you look at your own data at any time.
  • .NET when the job calls for heavy background processing or has to fit into an existing Microsoft environment.
  • Everything under version control in a repository you own, with a deployment pipeline so each change is checked before it goes live.

Start a project

From idea to signed contract, without the back-and-forth

Tell us what you need and get a proper plan back — usually within one business day.

  1. Step 1

    Describe it in plain English

    Three short steps in your own words. No specs, no jargon, no forms that assume you already know what you need.

  2. Step 2

    We check it's a fit

    Every submission is screened for safety and legitimacy before it reaches our team — so real clients get a fast answer and nobody else gets through.

  3. Step 3

    AI turns it into a real brief

    Scope, user stories, acceptance criteria, risks, and the questions worth asking — prepared for you, so we both start from the same understanding.

  4. Step 4

    Quote, agree, sign

    A clear quote with milestones you can accept or counter, then a plain-English contract you sign online. No surprises, no lock-in.

Start your project

You'll create a free account first — it's how we keep your project details private and your contract tied to you.

We have built this before

Every product below is live, built and run by this studio. Each case study covers the problem, what we built, and the parts that were genuinely hard.

Guides worth reading first

Related

Common questions

How much does web app development cost?

A first version starts from A$2,500; builds with several user types, payment flows, or third-party integrations tend to land as a Custom Engagement from A$4,500. Either way, the figure you get after the free 30-minute consultation is a fixed quote tied to a written scope, not an estimate. If what you actually need is a marketing site with a contact form, a Starter Website from A$900 will serve you better.

How small should a first version be?

Small enough that one type of user can complete one valuable task from start to finish — sign up, do the thing, pay or see the result. If a feature isn't required for that loop, it goes on the after-launch list. Scentena, for example, runs with no user accounts at all, because the formula builder is the whole point.

Can you build an internal tool rather than a customer-facing product?

Yes, and it's often the better first project: the users are your own staff, the requirements are clearer, and the return shows up as hours saved every week. Typical examples are approval queues, job trackers, and admin screens that replace a shared spreadsheet. The same scope, quote, and handoff process applies.

Will I be able to change things myself after launch?

For content, prices, and settings, yes — the admin area is built so you don't need a developer for everyday changes. New features or changes to how the app works are development work, which we quote as a second phase or handle under a maintenance plan when they're small.

Do I have to keep paying you once the app is live?

No. Once the final invoice is paid there are no ongoing fees to us unless you choose a maintenance plan. Hosting and payment-provider fees are billed to you directly, because those accounts were opened in your name.