Building the next app should cost a lot less than the first one

The first internal app is expensive for reasons that have little to do with the screen. Someone has to decide where it runs, how a person signs in, which data it may read, which model it may call, and how the code is reviewed before anyone else depends on it. That work is real. Doing it again, from scratch, for the second app and the tenth, is how a company stays busy and still feels behind.

Building the next app should cost a lot less than the first one. Once the foundation is in place, the next workflow should reuse it. The sign-in you already trust. The data that has already been certified for this kind of use. The connection to the model. The place the code lives. A review that applies to the capability, not a new committee for every form.

Think of the foundation as a short list, not a brochure. Cloud, so there is a place to run. Data, so there is a source someone will stand behind. A model gateway, so calls go through a front door you can see. Identity, so the app acts as the person using it. Code, so what shipped is what you can read next month. Those five are enough to make the second build feel different from the first. You are no longer negotiating the ground rules. You are deciding what this particular workflow needs.

Leave one of them out and the savings disappear. No shared identity, and every app invents a login. No gateway, and every app calls a model from a key someone pasted in a file. No certified data, and every app arrives with its own spreadsheet. The list is short because each item removes a whole class of repeated work. It is not short because the work is optional.

The economics show up in the review. Security review once per capability. If a team has already been cleared to read a certified dataset through the gateway, the next app that needs the same read should not start the conversation over. The new questions are the ones that are actually new: what the app does with the row, who can run it, and what happens when it is wrong. That is a smaller meeting. It should be.

People worry that “once” means careless. It means the opposite, aimed at the right object. You review the door thoroughly, and you stop reviewing the door every time someone walks through it with a new question. A change to the door is a new review. A new question, asked by someone already allowed in the room, is not a new door. Teams that review both, every time, teach their builders to avoid the official stack.

It also shows up in how trust accumulates. A sensible lifecycle is Draft, then Shared, then Certified. Draft is one person’s working copy. Shared is a team relying on it, with an owner. Certified means the data and the access have been reviewed and other people are invited to build on it. The first app pays to climb that ladder. The next app starts higher, because the rungs already exist. Components that survived review get reused instead of redrawn. A studio where people assemble those pieces is how the second team avoids rebuilding the login and the audit trail.

Certified is a high bar on purpose. Most things should live for a while as shared work with a name on them. The cost drops anyway, because shared already means the foundation was reused and a person is accountable. Certification is for the pieces other teams will build on. If everything is certified, the word means nothing. If nothing is, every team starts from a draft forever and you never get the cheaper second app.

This is ordinary shared-infrastructure economics, applied to software your own people build. The cost per use falls as more of the company uses the same foundation. The mistake is to treat each app as a fresh purchase of that foundation: a new stack, a new vendor login, a new extract, a new exception to the identity standard. Each of those feels small. Together they are why the next app costs what the first one did, and why teams go around the process.

None of this requires every workflow to look the same. Bespoke is the point. The invoice chase, the regional readout, and the handoff from sales to operations are different products. They should not each invent a different way to prove who the user is. Sameness belongs in the foundation. Difference belongs in the workflow. A company that standardizes the workflow ends up with software people work around. A company that standardizes nothing ends up paying first-app prices forever.

A practical test: take the last internal tool you shipped and list the weeks that were not the workflow itself. How much of that list would still be on the critical path for the next tool? If the answer is almost all of it, the foundation is not in place yet, and the next app will cost what the first one did. If the answer is the part that is actually new, you are in the right shape.

Keep the foundation boring, reviewed, and shared. Spend the team’s attention on the work only this company does. That is the whole saving. It shows up on the second app, and it compounds on the ones after that, as long as nobody is allowed to rebuild the ground rules because they are in a hurry.