Functional design template for custom software

Introduction

The most expensive sentence in software projects is: "I assumed that was obvious." Almost every budget overrun we encounter with new clients traces back to work the client expected but never wrote down, or work the agency assumed but never confirmed. The instrument that prevents this has existed for decades and is called a functional design: a document that records what the software must do, for whom, and when it counts as done.

In this article you will find a complete functional design template you can use directly when you commission a web application. Not an academic requirements handbook, but the structure we use ourselves at MG Software in Haarlem for portals, dashboards and internal tools. For each chapter you will read what belongs in it, which questions you need to answer, and which mistakes we see most often in practice.

Why a functional design earns money instead of costing it

To many business owners a functional design feels like a delay: there is a problem, there is budget, why not just start building? The answer lies in the cost of change. A missing requirement that surfaces while writing the FD costs a paragraph. The same requirement surfacing during the build costs days of rework. And if it only shows up after delivery, add meetings, frustration and sometimes a dispute over additional work.

There is a commercial reason too. Agencies quoting against a vague brief add a risk premium, and rightly so: they do not know what "a simple portal" means in your context. A clear FD removes that uncertainty. In our own quoting practice we see that projects with a worked-out FD can be priced more sharply than projects where we have to guess the scope, simply because we need less buffer for surprises.

Finally, the FD is your main steering instrument during the project. Every new wish that comes up during the build, and they always do, can be tested against the document: if it is in there, it is part of the agreement; if not, adding it becomes a conscious decision to adjust scope, budget or planning. Scope creep changes from a silent problem into an explicit choice.

Chapters 1 and 2: purpose, context and users

Every good FD starts with half a page on the why. Which business problem does the software solve, what does that problem cost today, and how will you measure that it is solved? Write it concretely: "staff currently look up order information in three systems and therefore answer twenty status emails a day" is usable, "we want to digitise" is not. This chapter also forces you to write down what the software does not do, and that boundary is at least as valuable as the wish list.

Then come the users and roles. Describe each role with a name, number of users, technical skill level and main tasks. A client portal quickly has three to five roles: the customer, an administrator at your company, an employee handling files, sometimes an external party such as an accountant. For each role, record what they may see and may do. This later becomes the basis for the permission model, and mistakes here propagate into every page of the application.

A mistake we see often: the FD only describes the happy flow of the end customer and forgets the internal administrator. Who activates new users, who resets passwords, who corrects a wrongly uploaded document? Admin functionality is rarely exciting, but it determines whether your team can run the system independently or has to call the builder for every small issue.

Chapters 3 and 4: user journeys and business rules

User journeys describe step by step how a role performs a task: a customer submits a request, an employee reviews it, the customer gets notified. Write out the steps, the screens involved and the decision points per journey. You do not need to be a designer; numbered steps in plain language are enough. Nielsen Norman Group has a good introduction to journey mapping if you want a more structured approach.

The trouble hides in the exceptions. What happens when a customer withdraws a request while it is already being processed? What if a document is too large, a payment fails, or two employees open the same file? Our rule of thumb: every user journey should come with at least two or three exception scenarios. It is exactly these edge cases that cause change-order disputes when they are only discovered mid-build.

Business rules deserve their own chapter, separate from the screens. Think of: a quote above 10,000 euros requires approval from a second person, a file can only close once all documents are reviewed, VAT is calculated under regime X. Rules change more often than screens; by documenting them separately, the development team can also build them separately, and you can adjust them later without tearing up the whole design.

Chapters 5 and 6: data and integrations

The data chapter answers three questions: which data does the system record, where does it come from, and which system is the source of truth when data exists in multiple places? That last point, ownership, is crucial. If customer data lives both in your CRM and in the new portal, the FD must state which system leads and how changes synchronise. Ambiguity here is a classic source of data pollution.

For each integration, describe the target system, the direction of the data flow, the frequency and what should happen when the connection fails. "The portal fetches open invoices from Exact Online every night; if the connection fails, the user sees the last known data with a warning" is a complete requirement in one sentence. In almost every project, integrations are the biggest cost item after core functionality, so vague wording here translates directly into diverging quotes. You can read more on our page about software integrations.

Do not forget data migration. Almost every system replaces something: an Excel sheet, an outdated package, a folder full of PDFs. The FD must state which historical data comes along, how clean that data is and who does the clean-up. We have seen projects where migrating ten years of polluted customer data took more time than building the portal itself; you want to know that upfront, not in week eight.

Chapter 7: non-functional requirements, the forgotten half

Non-functional requirements describe not what the system does, but how well it does it: speed, availability, security, scalability, usability. They are invisible in a demo, which is why they get skipped most often, even though they heavily determine the architecture and therefore the price. A dashboard for five employees is fundamentally different from the same dashboard for five thousand customers who all open it at nine on Monday morning.

A useful framework here is the ISO 25010 quality model, which splits software quality into characteristics such as performance, reliability, security and maintainability. You do not need to elaborate every characteristic; pick the five that matter for your situation and make them measurable. "Fast" is not a requirement; "search results appear within two seconds with a hundred concurrent users" is.

Security deserves extra attention here, especially now that the Dutch Cybersecurity Act takes effect on 15 August 2026 and in-scope clients are pushing security requirements onto their suppliers. Record at minimum: how users log in (password, two-factor, SSO), which data must be encrypted, how long logs are retained and who has access to production data. Retrofitting these requirements is many times more expensive than including them from day one.

Chapter 8: acceptance criteria, or when is it done

"A functional design is not paperwork for a drawer. It is the cheapest place in the entire project to change your mind."

— Jordan Munk, co-founder MG Software

The final chapter is the most important one: how do client and builder jointly establish that the work is finished? For each user journey, write testable criteria in the form "given situation X, when the user does Y, then Z happens". This format forces precision and doubles as a test script at delivery. Vague criteria like "the portal works to satisfaction" are a recipe for dispute.

Also agree on the acceptance process itself: who tests, within how many working days after delivery, and what happens with findings? A workable arrangement is that blocking defects hold up acceptance while cosmetic items go on an aftercare list. Without such an agreement, a project lingers for months in a grey zone where it is "almost done" and nobody dares to send the final invoice.

On one of our projects for a wholesaler in Haarlem, this chapter produced the biggest insight of the entire engagement. While writing the acceptance criteria for order statuses, it turned out that sales and logistics had been using different definitions of "delivered" for years. The difference had never surfaced because both departments worked in their own Excel files. One working session later, a single definition was on paper, and that discussion never came back during the build.

How we use the FD during the build

At MG Software the FD is not a one-off document but a living contract. Before the start, the client validates every chapter; during the build we check every sprint against the document and update it whenever we consciously deviate. New wishes get a simple routine: we estimate the impact, the client decides whether it is added, traded against something else or parked for phase two, and the FD is updated. Nothing disappears into a mailbox.

That discipline sounds strict but actually creates calm. The client knows at any moment what is and is not part of the agreement, and the team does not quietly build features nobody asked for. At delivery we walk through the acceptance criteria from chapter eight one by one. No surprises at the final invoice, no debate about what "done" means.

Would you rather start with a rough cost indication before writing a full FD? You can: our calculator gives you a range within two minutes based on the type of application, the number of roles and the desired integrations. With that indication you can reserve internal budget and then focus the FD on the parts that drive the price most.

Conclusion

A good functional design is the best investment you can make before a single line of code is written. The template in this article, purpose and context, users and roles, user journeys, business rules, data, integrations, non-functional requirements and acceptance criteria, is deliberately generic: it works for a client portal, an internal dashboard and a full web application.

Want to spar about the FD for your project, or would you like us to do the writing based on working sessions with your team? Get in touch. And if you are curious what your application will roughly cost, start with the calculator or read our article on what a client portal costs in 2026.