How to plan a custom web app

A useful custom web app starts with a task someone needs to complete. That might be arranging a lift, approving a request or moving an order through the business. Describe that task clearly before deciding which screens and features to build.

You do not need a finished technical specification to start a conversation. A short account of the problem, the people involved and the systems they use gives a development team something concrete to work with.

Start with the task that matters most

Choose a situation that happens regularly. Walk through it from the first request to the final result. Who starts it? What information do they need? Who makes a decision, and how does the next person know they can continue?

Bring a real example, with private information removed. A spreadsheet, a form or a description of the current process is often more useful than a long feature list. It exposes the details that are easy to miss in an initial idea.

• Who will use the app, and what are they trying to do?
• Where does the current process become difficult?
• What should a person be able to complete in the first release?
• What would make you confident that the change is working?

Decide what belongs in the first release

The first version needs a complete route through the main task. A customer should be able to submit a request and receive a clear outcome. The person handling it needs the right information and a way to deal with problems.

Keep a separate list of ideas that can wait. Additional reports, extra user roles and new payment options can each introduce work beyond the visible screen. Discussing them early helps the team leave room for them without committing to everything at once.

For ViaVia, we worked with the client from planning and prototypes through the brand, website and app. Invitations, trust connections, journey requests and trip chat support the practical task of arranging a lift. The public website explains the idea before someone joins. That relationship between introduction and use is part of the product, alongside the app features themselves.

List the connections and access rules

Write down which existing services the app must use. Payments, maps, accounting and customer records may each depend on an outside provider. Confirm that the required access is available and that the intended use is supported before treating an integration as agreed scope.

Describe who can see and change each type of information. A member, an administrator and a support person may need different access. Include what happens when someone leaves, loses access or asks for a record to be corrected.

ViaVia combines its custom application with services for authentication, subscriptions, maps and browser notifications. Its case study shows why planning the connections matters: the visible experience relies on several parts working together.

Test the whole journey before launch

Agree acceptance checks in language everyone understands. “A member can request a journey and see its status” is easier to review than “the request module is complete”. Add checks for missing information, denied access and an unavailable service.

Ask people who are likely to use the app to try realistic tasks. Watch where they hesitate. Check the phones and browsers they actually use, including slower connections where relevant. A successful demonstration by the development team is only one part of that review.

Agree what happens after launch

Before the handover, confirm ownership of the domain, hosting, service accounts and source code under your agreement. Decide who handles updates, backups, monitoring and support. Record the recurring services the app depends on and who pays for them.

Choose a few useful measures for the first release, such as completed tasks, failed requests or the number of records needing manual attention. Those observations can guide the next phase more reliably than adding features simply because they were on the original wish list.

What should you send us first?

Send the problem you want to solve, a sample of the current process and the names of any systems involved. Tell us who will use the app and any deadline that affects the project. We can help turn that into a sensible first phase through our custom software and app development service.

If you are still deciding whether to build, start with our guide to custom software and off-the-shelf options.