At this stage static markup starts responding to what people do. A form flags an error before it is submitted, a button will not let anyone place the same order twice, and a screen honestly shows that it is loading instead of freezing. This is where users decide whether the product is comfortable to work with, and this is where leads get lost if a scenario was only thought through for the ideal case.
It is also where one of the most common weaknesses in custom products is built in: the belief that client-side checks guarantee anything. Below we look at what goes into the sixth stage of our app development strategy, what it costs and where the line between interface and server runs.
What happens at this stage
- Interactive scenarios built in JS/TS: multi-step forms, filters, search, baskets, calendars, configurators.
- Dynamic forms, validation and user behaviour: dependent fields, hints, totals that recalculate when parameters change.
- Loading, error and empty-list states. The things nobody remembers to design, yet users see every day.
- Protection against repeated actions: the button is locked while a request is in flight, and entered data survives an error.
What you get at the end
- An interface in which the scenarios from the technical specification run from start to finish.
- Forms with clear error messages in the user's language, not "something went wrong".
- Screens that behave predictably on a slow network, with empty data and when the server returns an error.
- Ready connection points to the server side, where the rules are checked for good.
How much interface logic costs
In the Ingello price list the interface logic stage costs from $0 to $4,700, and the price is fixed before work starts. The lower bound means that a simple product with little interactivity may not need a separate budget. The upper end is made up of several factors:
- how many scenarios there are and how many steps each has;
- how complex the forms are: dependent fields, calculations, file uploads;
- how many roles see different screens and different sets of actions;
- whether real-time updates and work on a poor connection are needed.
Client-side validation is convenience, not protection
Client-side checks exist so users learn about a mistake straight away rather than after submitting. But they do not protect the data: any request can be sent around the interface. That is why every rule that matters to the business must also live in the server-side business logic, and access to actions must be closed off as described in our article on security.
A simple example of the split. The interface shows a countdown for a temporary seat hold on a bus, as in our bus booking system. But whether the seat is free and when the hold expires must be decided by the server. If the browser decides, sooner or later two passengers will buy the same seat.
How we describe the logic before writing code
Interface logic is cheapest to fix on paper. In the FitProt fitness app case, every questionnaire field in the specification is mapped straight to a table and column, with a rule attached: height and weight accept digits only, three at most. The same document describes the "Complete workout" button: it increments the completed-sessions counter and closes the entry in the training log. Started and finished on the same day, the entry is updated. Finished the next day, a new one is created.
This level of detail looks excessive until development begins. After that it saves weeks of arguing about how things were supposed to work.
A second example is the TempRes CV builder. It is a reactive app on top of a ready-made API with 27 endpoints documented in Swagger. The user fills in a form and the CV preview updates alongside it. The API already existed, so the quality of the product for the user came down entirely to the interface logic.
Roles change the interface
Interface logic also covers who sees what. In the BusTicket admin system, the owner, route manager, partner carrier, dispatcher and agent all log into the same system, but each sees only their own menu. Fewer unnecessary buttons, fewer accidental mistakes, easier onboarding for new staff. A hidden button is still only a convenience, though: the action itself is locked by permissions on the server.
What breaks if you cut corners
The product looks like it works and behaves unpredictably at the edges:
- a double form submission creates two orders or two payments;
- a dropped connection leaves the interface stuck on an endless spinner;
- a server error wipes out everything a person spent ten minutes typing;
- the error message says "something went wrong" and the customer goes to a competitor;
- client-only checks let bad data into the database, which then has to be cleaned up by hand.
To an owner this looks like "fewer leads than the traffic suggests", even though the advertising is working.
What we need from you
- Scenarios from the specification or prototype, stating what counts as successful completion.
- Field rules: what is required, which formats, which limits.
- Error message texts, or agreement that we write them.
Where next
Next come integrations: payments, CRM, maps and real-time data exchange. The previous step: front-end markup. The map of all stages is in the app development strategy.
If you already have an interface but leads are getting lost in the forms, let us discuss it at a free consultation with an architect. Afterwards you will receive a price and timeline estimate broken down by stage.
