When a business web app goes wrong, people usually blame the build. The agency was slow. The developer misunderstood the brief. The budget ran away. The launch date slipped by three months and everyone started speaking in shorter emails. Fair enough. But in most cases, the real damage happened much earlier, when the project was still a document, a few meetings and a lot of assumptions.
The uncomfortable truth is that many companies start custom development with a vague wish list dressed up as a specification. They know they want a client portal, booking system, staff dashboard or internal workflow tool, but they have not properly defined what the thing must do, who it is for, what success looks like or what should wait until phase two. That is how a sensible €25,000 project becomes a €60,000 argument.
If you are paying for a web app, the spec stage is not admin. It is the project. Get that part right and build becomes straightforward. Get it wrong and even a talented team will spend months translating fuzzy thinking into expensive rework.
The spec is where budgets are won or lost
Business owners often treat specification as a delay before the real work starts. They want screens, timelines and visible progress. A proper discovery and specification phase can feel slow because there is nothing flashy to show at the end of week one. But that is exactly why it matters. It forces decisions before those decisions become costly.
Let's put numbers on it. If changing a requirement during planning costs €500 in meetings and revisions, changing it halfway through build can cost €3,000 to €8,000 once design changes, extra development, retesting and launch delays are added in. If the app is tied to staff training, marketing or operational change, the knock-on cost is higher again. One late decision can affect six other parts of the project.
A Cork services company we worked with wanted a custom client portal for bookings, document sharing and invoice tracking. Their initial brief was six pages long and sounded clear enough. After a proper specification workshop, we found 23 missing rules around user roles, approval steps and billing exceptions. Had those surfaced during build, the project would likely have stretched from 14 weeks to 22 and added roughly €12,000 to €18,000 in extra work. Instead, they spent three weeks tightening the spec and launched in 16 weeks with a controlled scope.
Most specs describe features, not decisions
Here is the usual problem: businesses write lists of features instead of making decisions. They say things like "users can upload files", "admins can manage accounts" or "customers receive notifications". That sounds useful, but it is not enough to build from. What files? What size? Who can see them? Can they be replaced? Are notifications email only, or text as well? What happens if someone ignores one?
A feature list creates false confidence because it looks complete. It is tidy, bullet-pointed and often signed off by several people. But unless it deals with edge cases, permissions, approval flows, exceptions and business rules, it is not a real spec. It is a wish list. And wish lists are dangerous when someone is estimating time and money from them.
This matters especially for internal systems where the process is messy in real life. A company might say they need a simple approval workflow, then casually mention in week five that regional managers can override head office, except on contracts over €10,000, unless the client is already active, in which case finance must review it first. That one sentence can add another screen, another user role, another reporting requirement and another round of testing. The feature did not change. The decision did.
If everyone wants something, your app is already in trouble
One of the clearest warning signs at spec stage is when too many stakeholders are trying to get their own needs into version one. Sales wants reporting. Operations wants automation. Finance wants approval controls. Customer service wants message history. Marketing wants campaign tracking. None of these are unreasonable requests on their own. Together, they create a bloated first release that solves nothing particularly well.
The strongest specs are opinionated. They define what the first version is for and, just as importantly, what it is not for. A version one app should solve a painful, frequent problem for a clearly defined group of users. It does not need to satisfy every department by launch. In fact, trying to do that is one of the quickest ways to produce a slow, confusing system that staff avoid using.
A Dublin retailer came to us after an 11-month attempt to build an internal stock and order management tool with another supplier. The original scope tried to serve warehouse staff, store managers, finance and e-commerce support in one go. By month nine, there were 47 requested changes and no launch date anyone believed. The reset was brutal but necessary: version one focused only on warehouse receiving and stock discrepancies. That reduced the number of core user tasks from 18 to 6, cut training time from an estimated two days to half a day and got the first release live in 10 weeks. Within three months, stock discrepancy resolution time dropped by 38%.
Good specs are built around user behaviour, not org charts
Many web app projects are specified according to internal departments rather than actual user behaviour. That sounds harmless, but it leads to awkward systems because people do not use software according to your company structure. They use it according to urgency, habit and convenience. If the app does not reflect that, they work around it with spreadsheets, email chains and WhatsApp messages.
A better approach is to define the top tasks each user must complete, how often they do them and what gets in their way now. For example, a field sales rep may need to submit a quote request in under two minutes from a phone in a car park, while a finance manager may review payment exceptions once a day on a desktop with more time and context. Those are completely different conditions, even if both are in the same system.
When you specify around behaviour, better priorities become obvious. Speed matters more than reporting for one user. Clarity matters more than flexibility for another. This also sharpens commercial decisions. If 80% of usage will happen on mobile, then mobile usability is not a nice extra. If the majority of value comes from reducing admin time, then dashboards can wait while workflow automation comes first. A spec should reflect where the money is saved or made, not who had the loudest opinion in the meeting.
The right question is not "what do we want?" but "what must be true?"
This is where many projects grow up. Instead of asking stakeholders what they want, ask what must be true for the app to count as successful. That changes the conversation from preference to outcome. It also cuts through vanity features very quickly.
For example, a membership organisation might say they want a member portal, event booking, downloadable resources, account updates and a private messaging area. Fine. But what must be true after launch? Perhaps member support emails should fall by 30%, event bookings should take under 90 seconds, and staff should stop manually updating renewal records. Now the priorities are clearer. If private messaging does not support those outcomes, it can wait.
This way of specifying also makes budget conversations more honest. If the available budget is €35,000 and the desired feature set points to €55,000, the answer is not to squeeze harder and hope. The answer is to decide what must be true in phase one. That is not cutting corners. It is managing risk. A focused release that solves one expensive problem is better than a sprawling release that introduces five new ones.
What a business-ready spec should actually include
You do not need a 70-page document full of technical language to specify a web app properly. You do need enough detail to remove ambiguity. In practice, a solid business-ready spec usually covers user types, top tasks, process flows, key screens, rules, exceptions, integrations, reporting needs, launch priorities and what is explicitly out of scope. It should also define success in measurable terms.
A useful checklist looks like this:
- Users: who uses the app, what they are allowed to do and what devices they use
- Top tasks: the 5 to 10 actions that matter most, in order of importance
- Rules and exceptions: approvals, limits, edge cases, deadlines and permissions
- Data: what information is captured, who sees it and what must be reported
- Integrations: what other systems the app must connect to, if any
- Priorities: what must be in version one and what can wait
- Success measures: time saved, error reduction, conversion improvement or admin reduction
Most importantly, someone on the client side has to own these decisions. Not five people. Not a committee. One person can gather input, but one person must be accountable for trade-offs. Without that, the spec becomes a diplomatic document designed to keep everyone happy, and that is exactly what breaks projects.
Here is the practical takeaway: if you are planning a custom web app, spend more time than feels comfortable on specification. Force the awkward decisions early. Define version one narrowly. Write down the rules people assume are obvious. Measure success in business terms, not feature count. If the spec feels a bit ruthless, that is usually a good sign. Ruthless planning is far cheaper than polite confusion halfway through build.