From choosing a stack to running at scale — how custom web applications are scoped, built, launched, and kept alive long after handover.
Most guides hand you a list of headings and wish you luck. This one shows you how each sentence you write turns into developer days and money: the screen rates we estimate with, what a second user role really costs, why one line about an integration can outweigh a month of work, and the arithmetic that lets you price your own project to within about 30 percent before anybody quotes you.
Most articles on this subject stop at "buy a maintenance plan". This one walks through the real twelve months after handover with the hours and the money written out: how noisy the first month is, the four kinds of work that never stop, what a year of care actually costs, and the four honest ways of owning it. It also says plainly where we tell a client to buy less support than we would happily sell them.
Your update has said eighty percent for three months and you have no way to test whether that is true. This article gives you five checks you can run in an afternoon with no technical knowledge, the simple arithmetic that turns finished work into an honest launch date, the real split of effort hiding behind the screens, and the four levers left when you discover you are behind, including the point where stopping is the right answer.
A successful app follows a clear path from discovery to launch. Knowing the stages helps you plan time and budget.
Scalability is designed in, not bolted on. These principles keep an app fast as users and data multiply.
The stack you pick shapes cost, speed and how easily you can hire and scale later. Here is how to choose wisely.
Custom is not always the answer — but when your workflow is your edge, a tailored app beats any template.
Most comparisons of these two paths stop at a feature list, so this one hands you the arithmetic we actually run with clients instead: what the sellable layer adds on top of the very same screens, what each path costs to run every month, how many paying customers it takes to break even, and the honest cases where buying something ready-made, or simply keeping the tool internal, is the smarter purchase.
Most articles on this subject list a few vague symptoms and then sell you a build. This one hands you the arithmetic instead: what your spreadsheet really costs per week in hours and money, the row counts and editor numbers where a file genuinely stops coping, a three year comparison you can check on a calculator, and the honest conditions under which we tell a client to keep the sheet and spend the money somewhere better.
Most guides to this question give a vague range and stop. This one hands you the whole calculation: the price bands we quote in practice, where the money goes inside a build, the yearly bill that arrives after launch, and the five year totals for renting against building set side by side at 40 users and at 80. It also names the cases where we tell a client to buy something ready-made instead.
