What you can actually build for $25,000

$20,000 – $31,000 covers one app that runs on iPhone and Android without being written twice, with sign-in and a notification when something on the account changes, for one kind of person. You have a logo, no screens are drawn, and there is nothing running behind it yet.

• 01

  Somebody downloads it, signs in, and sees the things that belong to them.

• 02

  They get a notification when one of those things changes.

• 03

  Everyone using it sees the same kind of screen, because everyone using it is the same kind of person.

• 04

  Nobody on your staff logs into it. Whatever they need, they get somewhere else.

That's a real product and businesses run on things exactly this size. It's also a genuinely narrow one, and the narrowness is doing the work: everything on this page is about what happens to the number when the description picks up a second audience. Price your own list and take things off until it lands.

Five things, spanning six to one, and each one is half a sentence when somebody mentions it. Each figure below is that one change and nothing else, added to the same build.

+$15,000

It keeps working with no signal

+$13,500

Your staff get a web application of their own

+$6,000

People pay by card inside it

+$5,000

A second kind of person, on their own screens

+$2,500

People take photos with it

Notice which two are furthest apart, because it isn't the pair anybody expects. A second kind of person, on separate screens with separate permissions, is $5,000. A web application for your staff to work in is $13,500 on a build this size, nearly three times as much, because that one isn't a feature at all. It's a second piece of software with its own screens, its own permissions and its own testing, described in half a sentence. What an office application really contains is the long version.

Working with no signal is the dearest of the five at $15,000, and it's the other one that's secretly two things: holding the work on the phone, then sorting it out when the phone comes back. Card payment is $6,000. Photos barely register.

Sometimes, and less than you would guess from the platform alone. Carrying the same features, two kinds of user on the web is $23,000 – $35,000 and the same two on phones is $24,000 – $37,000. The platform is worth about $1,500. What actually decides the budget is whether your staff need a desk-sized application of their own, which takes the phone version to $35,000 – $52,000.

On phones, two audiences

$24,000 – $37,000 if both audiences work inside the app itself. $35,000 – $52,000 once your staff need a desk to work at, because that's an app and a web application on one budget.

On the web, two audiences

$23,000 – $35,000. One application, two sets of screens inside it, no app store review and no list of phones to test on. It opens on a phone browser too, which is often all the mobile anybody needed.

So the question isn't really web or phone. It's whether the people doing the work have their hands full. A tech in a crawl space needs it in a pocket. Somebody at a desk does not, and the reason web wins at this budget is that a desk audience gets rooms in a building you already put up, where a phone audience gets a second building.

It's enough for one piece of software. It runs out the moment a second one appears, and the tell is a sentence beginning "and then the office".

What $25,000 fits

One app, one kind of user, and two or three things it does. A business that can answer a question inside a week. Photos are the cheapest thing on the list at ${gap(TWENTY_FIVE_PLUS_PHOTOS, TWENTY_FIVE)}, though even that puts the top of the range at ${usd(TWENTY_FIVE_PLUS_PHOTOS.cost.high)}.

What it doesn't

A second application, which is what "our staff need to manage it" means. Anything used where there is no signal. And anything that has to talk to a system nobody has documented, because that price is set by the other system rather than by yours.

There's a floor underneath, and it's closer than it looks. A build with nothing on it is $14,000 – $21,000, so $25,000 is buying one foundation plus about two real features. Why $10,000 doesn't reach has the arithmetic underneath that, and what $50,000 buys is the next bracket up, where the office side fits.

Two moves, and both are about the description rather than the build.

• 01

  Count the pieces of software before you count the features. If your description contains two of them, that is the thing to fix, and postponing one is reversible in a way that the thing underneath isn't.

• 02

  Say what already exists. If designs are drawn or something already works behind the app, say so in the first paragraph. Both take real money off, and both get left out of descriptions constantly.

The office application is the specific thing to postpone rather than shrink. A spreadsheet, a shared inbox or a database screen will run the back of a young product for a year while you find out what your staff need to see, and building it then means building it once. That's deciding what belongs in a first version, applied to the half of the project nobody demos.

The concrete version of that: sign-in and one job, on both phones, with notifications left until people are using it, prices at $18,000 – $28,000. That's the same product a month later than the version with notifications in it, and the difference stays in your hand for whatever the first month of real use turns up.

11–16 weeks, kickoff to installable, store review included. Adding the office application takes the money up by $13,500 and the calendar to 13–20 weeks, which is the useful thing to know: a second piece of software costs you far more in money than in weeks, because two teams can build two things at once.

About a fifth of the calendar is fixed whatever you spend: kickoff, the rounds where you look at something and say what's wrong with it, and the store queue. The rest does compress, which is the reason a second piece of software adds a lot of money and only a few weeks.

The part to protect at this size is the gap between the store approving it and your own people trusting it. That gap is weeks of somebody watching how the first users behave, and it is what a tight budget tends to spend before it arrives.