Custom web application: use cases, architecture, costs and development method

A web application is not a site to which a user account is added. It is a work tool or a transactional service for which the company will have to assume responsibility for the rules, data, incidents and evolution.

1. In short: when a tailor-made web application is rational

The development of a web application consists of designing, building and operating software accessible from a browser, capable of executing business rules, managing states and rights, exchanging data and supporting repeated journeys.

Tailor-made becomes rational when the process to be digitized creates an advantage, when no product on the market covers it correctly and when the organization knows how to maintain the service over time. It becomes expensive when the only difference is interface preferences, unarbitrated exceptions or the desire to reproduce standard software.

Before funding a line of code, management must be able to defend four assertions: the problem actually costs something; users encounter it quite often; the first scope is likely to improve an observable measurement; the company accepts the operating cost after delivery.

2. Key figures: cloud, delivery, availability and quality of the Web

The numbers describe different perimeters. They neither prove that a cloud application will succeed nor that sophisticated architecture is necessary. Their convergence is more useful: the technical base is accessible, while the ability to choose, deliver and exploit remains the rare factor.

3. The investment file: nine hypotheses to be made falsifiable

A specification often lists screens. An investment case describes hypotheses that the team can confirm, correct or abandon. This difference avoids locking the project into a solution before having understood its value.

3.1. Hypothesis 1 — The problem deserves a product

Measure the current cost: re-entry hours, errors, lost files, avoidable calls, delays, abandoned margin, compliance risk or inability to sell a service. An irritant does not automatically become a product. If it occurs twice a year and resolves within ten minutes, a clear procedure is probably enough.

The useful deliverable fits on one page: population concerned, frequency, unit cost, existing alternatives, annual impact and owner of the result.

3.2. Hypothesis 2 — Off-the-shelf software is not enough

The build-or-buy comparison must be based on a real-world scenario. Select three credible solutions, configure a critical flow with representative data, and document deviations. Then classify them: configurable, bypassable, blocking or voluntarily abandoned.

Tailor-made is defensible when the blocking gaps touch the heart of the model: specific pricing, specific coordination, field constraints, differentiating experience or decisive integrations. It is much less so for reproducing invoicing, CRM, document management or standard authentication.

3.3. Hypothesis 3 — A first perimeter can produce a proof

The first batch is not half of a large application. It must allow a segment of users to complete a task end-to-end and produce a signal. A request entered but unable to be processed on the operations side does not constitute an MVP. A dashboard without associated decision either.

The alpha phase of GOV.UK recommends prototyping the riskiest hypotheses and reaching a sufficient level to decide whether to proceed or not. This logic applies beyond the public sector: the first investment buys a decision, not a miniature of the final dream.

3.4. Assumption 4 — Business rules are governable

The software encodes decisions: who is authorized to do what, in what order, with what supporting documents, what deadlines and what exceptions. If three managers give three different answers, the code will not reconcile the process. It will freeze the conflict.

Construct a decision table based on twenty to fifty real cases. For each case: entry, rule, exit, exception, responsible and proof. Disagreements resolved at this stage cost little. Those discovered in recipe cause rewriting, delay and distrust.

3.5. Assumption 5 — Data is available and lawful

Inventory the sources, owners, identifiers, formats, quality, frequency, retention period and legal basis. Test extreme data: absence, duplicates, encoding, old values, time zones, change of reference.

The good model is not the one that perfectly represents the world. It’s the one that makes important decisions explicit, allows for correction, and preserves necessary history.

3.6. Assumption 6 — Integrations have an actual contract

A “CRM connection” line often hides the main unknown. Does API exist for the license level purchased? Are quotas, deadlines, webhooks, authentication, test environments and credential ownership documented? What happens if the remote system is unavailable or returns the same event twice?

Before estimating, perform a technical tip on the riskiest path. A simulated screen reassures; an authenticated exchange with recovery on informed error.

3.7. Assumption 7 — Risk and service level are accepted

List the scenarios that matter: data loss, improper access, unavailability, calculation error, synchronization delay, accidental deletion. Each receives a probability, an impact, a prevention measure, a detection capability and a recovery procedure.

Then set service goals. Availability, response time, data freshness, error rate and recovery time must be linked to the business. A target of 99,99 % has no value if no one knows how to intervene at night; a target of 99 % risks being insufficient for a reservation which concentrates its turnover over two hours.

3.8. Hypothesis 8 — The team can deliver small changes

The quality of the product depends as much on the flow of decisions as on the framework. The minimal trio brings together an available business owner, a product/UX skill and a responsible technical skill. Depending on the risk, data, security, accessibility, exploitation and legal expertise are added.

Observe the flow: time from idea to production, batch size, review time, return rate, incidents after change, recovery time. These measures DORA avoid false management by number of tickets or lines of code.

3.9. Hypothesis 9 — The farm has an owner and a budget

After launch, dependency updates, rights requests, tickets, monitoring, backups, regulatory developments and product arbitrages begin. The run should not be the variable that will be discovered when the build budget is exhausted.

Name a service owner, a proportionate penalty, a maintenance schedule, a vulnerability process, data managers and an improvement envelope. An application without the ability to evolve becomes a debt from its first business exception.

4. Choosing architecture without paying for complexity over value

Architecture is a series of decisions that are reversible or difficult to reverse. It is not reduced to drawing boxes.

For a first product, a modular monolith, a controlled relational base, a queue for long processing and well-chosen managed services often form a better starting point than a distributed landscape. This advice Logiks is not a law: volume, compliance or organization may justify another path.

5. The product, its business rules and the capacity for change

The code comes later. The rules come first. The evidence is clear. Exploitation lasts.

This sequence seems simple, yet it modifies the management: the committee no longer validates an accumulation of screens, it authorizes a complete business capacity whose exceptions, data and responsibilities have been made visible before the acceleration of development.

The backlog then separates three types of work. The first directly produces a result for the user. The second protects the quality of the service — security, accessibility, testing, supervision. The third reduces an unknown factor likely to change cost or delay. Hiding the last two behind features creates flattering velocity and immediate debt.

6. Recommended method: six proofs before the next passage

6.1. Proof of problem

Interviews, work observation, usage data and current cost produce a cadrage. The committee decides to resolve, defer or discontinue. The functionalities remain secondary.

6.2. Proof of journey

A prototype with realistic data covers the happy path, errors and rework. Representative people carry out the task; the team records success, misunderstandings and workarounds.

6.3. Proof of feasibility

Dangerous technical unknowns are tested: API, volumetry, rights, calculation, degraded mode, import and export. The result is an architectural decision note, not a demo intended to be secretly put into production.

6.4. Proof of Service

The first increment crosses interface, rules, data, operations and support. It operates in an environment close to production. Logging, alerts, backup and restoration are tested before opening.

6.5. Proof of mastery

The recipe covers functional, security, accessibility, performance, data and operations. Acceptance criteria describe an observable outcome. The NIST SSDF provides a basis for organizing secure development; it does not replace the product-specific risk analysis.

6.6. Proof of value

Launch is limited to a controllable group or flow. The baseline is compared after sufficient time: processing time, completion rate, errors, cost per file, satisfaction, incidents and actual adoption. A local improvement is only worthwhile if it does not shift the burden to support or the business team.

7. Budget and deadlines: estimate a capacity, not a number of screens

The total cost can be represented as follows:

Discovery + design + construction + data/integration + quality assurance + launch + operation + evolution.

The main multipliers are rule variability, number of roles, criticality, integrations, migration, service level, regulatory constraints and volume of interface states. A dashboard screen seems simple; the reliable, traceable and reconciled calculation that powers it often represents the essence of the project.

Logiks benchmarks to be used only to frame a dialogue: a concentrated discovery often lasts three to six weeks; a first compact business service frequently requires three to five months; a platform with migration, multiple roles and integrations sometimes requires six to twelve months before a first stable reach. The calendar should show decision and data dependencies. These ranges are not market averages.

Compare offers on the same positions: research, prototype, environments, testing, security, migration, documentation, transfer, supervision, warranty, maintenance and property rights. The lower estimate sometimes simply excludes exploitation.

8. Decision table: buy, assemble, develop or abandon

9. Logiks Tips: Five Field Guardrails

1. Charge each exception twice in the estimate: once for code, once for testing and exploitation.
2. Demand a useful export early. The reversibility tested is worth more than a generic clause.
3. Demonstrate errors and incomplete cases; the ideal path hides the true cost of the product.
4. Track time to a business decision, not just team velocity.
5. Reserve some capacity for debt, dependencies and incidents from the first quarter.

10. Roadmap 30 / 60 / 90 days

10.1. Days 1 to 30 — Encrypt the problem

• observe the process and measure its cost;
• map users, rules, data, risks and existing solutions;
• select risky hypotheses;
• compare buy, assemble and build;
• define result, guardrails and stopping threshold.

10.2. Days 31 to 60 — Buy information

• prototype the complete course with error cases;
• test with users;
• carry out the integration points;
• establish the rights and data model;
• estimate build, run and release over three years.

10.3. Days 61 to 90 — Allow first service

• decide go, pivot or stop;
• establish the ownership team;
• cut out a workable increment;
• define quality criteria, SLO and measurement plan;
• prepare environments, security, support and recovery before accelerated development.

11. FAQ

11.1. What is the difference between a site and a web application?

A site mainly organizes relatively simple content and interactions. An application manages users, rights, persistent states, business rules, transactions and integrations. The border is not aesthetic: it concerns behavior and operational responsibility.

11.2. How much does a custom web application cost?

A universal figure would be misleading. The cost depends on the rules, roles, integrations, data, migration, criticality and service requirements. Ask for an estimate separating discovery, first perimeter, industrialization and exploitation over three years.

11.3. Should we start with an MVP?

Yes if “MVP” designates a minimal end-to-end service allowing a decision. No if it designates an incomplete interface that ignores data, operations, security and support. The perimeter must be small, but usable.

11.4. Microservices or monolith?

For a compact team and an unstable domain, the modular monolith often reduces the coordination cost. Separate services are justified when borders, charges, risks or truly independent teams require it. The decision must be able to be linked to an observed constraint.

11.5. How to choose the service provider?

Evaluate its ability to challenge the need, test the unknowns, show failure cases, document decisions and prepare for transfer. Ask for acceptance criteria, exclusions, code and data rights, security plan, and how incidents will be handled.

11.6. Who should own the product after launch?

An internal person must own the priority and the result, even if the technical operation is entrusted. The service provider is able to support the roadmap; it is not intended to permanently replace the arbitrage profession.

12. Conclusion

Developing a custom web application means transforming a process and a responsibility into a software service. The decision is only sound if the problem is quantified, the alternatives have been tried, the first increment produces proof and the operation already has a manager.

Good architecture is not the most impressive. It’s the simplest one that protects real constraints, reveals failures and lets the team learn without rebuilding with each decision.

13. Main sources

1. Eurostat — 53% of EU enterprises used paid cloud services in 2025, 3 February 2026.
2. CNCF — Annual Cloud Native Survey 2025, January 2026.
3. GOV.UK Service Manual — How the discovery phase works, accessed on July 13 2026.
4. GOV.UK Service Manual — How the alpha phase works, accessed on July 13 2026.
5. DORA — State of AI-assisted Software Development 2025, 2025.
6. DORA — How to enable software delivery teams to innovate with generative AI, accessed on July 13 2026.
7. Google SRE — Availability table, accessed on July 13 2026.
8. Google SRE — Production services best practices, accessed on July 13 2026.
9. HTTP Archive — Web Almanac 2025, Performance, published in 2026.
10. WebAIM — The WebAIM Million 2026, February 2026.
11. NIST—Secure Software Development Framework 1.1, accessed on July 13 2026.