Softomate Solutions is a London-based software development studio that has planned and built web applications for UK businesses across professional services, property, healthcare, and financial technology. The pattern we see in most failed projects is not bad engineering - it is inadequate planning. Businesses that invest properly in the planning phase consistently ship working software on time and on budget. Those that skip it consistently do not.
Discovery is the structured process of understanding the problem before writing a line of code. A proper discovery phase for a web application typically runs two to four weeks and produces the raw material everything else depends on.
Discovery involves four activities:
Stakeholder interviews. Talk to everyone who will use the application or be affected by it. A booking system touches the client making the booking, the staff member managing the calendar, the finance team processing payments, and the operations manager reading the reports. Each has different needs, different pain points, and different definitions of success. Discovering these conflicts during planning is free. Discovering them after building is expensive.
User research. If your application has external users - customers, suppliers, partners - you need to understand their mental model, not just your internal team's. User interviews, observation of existing workflows, and review of support ticket themes reveal what people actually struggle with. This is the work that separates applications that people enjoy using from applications that people use reluctantly because they have to.
Process mapping. Draw the current workflow end to end. Every step, every decision point, every handover between people or systems. This exercise almost always reveals inefficiencies, manual workarounds, and edge cases that nobody mentioned during interviews because everyone considers them normal. Process maps become the basis for your functional specification.
Competitor and market audit. Review what existing solutions exist. This is not to copy them - it is to understand the landscape, benchmark feature expectations, and identify where your application needs to be meaningfully better. Users bring expectations from every other application they use. If your booking flow is worse than Calendly, that is a problem regardless of how novel your product concept is.
Functional requirements describe what the application does. Non-functional requirements describe how well it does it. Both are essential, and most project failures stem from non-functional requirements being ignored during planning.
Functional requirements for a customer portal might include: user registration and email verification; document upload with virus scanning; role-based access so junior staff see different options than senior managers; a notification system for status changes; an audit log of all actions. These are the features - the things users interact with.
Non-functional requirements are harder to write but equally important:
Both approaches have genuine merit. The right choice depends on your situation.
A technical specification is a document that describes the system comprehensively: data models, API contracts, user interface flows, business rules, integration points, security requirements, and infrastructure. It is thorough and leaves little room for ambiguity. The advantage is that everyone - client and developer - agrees on exactly what is being built before work begins. The disadvantage is that writing a thorough spec takes time (three to six weeks for a complex system), costs money, and can be rigid if requirements evolve. Specifications work well when requirements are genuinely stable, when you are tendering the work to multiple agencies and need like-for-like proposals, or when you are working in a regulated environment where documentation is a compliance requirement.
A user story approach describes requirements from the perspective of the people using the system: 'As a finance manager, I can download a CSV of all invoices for a date range so that I can reconcile against my accounting software.' User stories are written incrementally, prioritised by business value, and refined continuously through development. The advantage is adaptability - the product evolves based on what you learn during building. The disadvantage is that fixed-price contracts are harder to write against user stories because scope is genuinely fluid. This approach works best with an experienced development partner on a time-and-materials or phased fixed-scope basis.
For most UK SME web application projects, a hybrid works well: a high-level specification that fixes the architecture, major feature areas, and non-functional requirements, combined with user stories that govern the detailed implementation sequence and allow flexibility on lower-priority features.
The monolith-versus-microservices debate is one of the most misapplied concepts in software discussions. For most UK business web applications - even complex ones - a well-structured monolith is the right choice.
Microservices are an organisational and operational pattern as much as a technical one. They make sense when you have multiple independent teams who need to deploy their components without coordinating with other teams, when different parts of the system have genuinely different scaling characteristics, and when operational complexity can be absorbed by a dedicated platform engineering team. Very few UK SMEs are at this scale.
A well-structured monolith - built with clear module boundaries, a layered architecture (presentation, application, domain, infrastructure), and a well-designed data model - can scale to tens of millions of users. Basecamp, GitHub, and Shopify all ran as monoliths for years. The real risk is not the monolith pattern - it is building a poorly structured monolith that becomes impossible to maintain. Good architecture in a monolith means enforcing module boundaries, avoiding direct cross-module database queries, and designing the data model carefully from the start.
If you later need to extract a high-load component as a separate service, a well-structured monolith makes that extraction straightforward. An unstructured one makes it a rewrite.
Tech stack selection for a custom web application should be driven by three factors: the requirements of the application, the availability of developers in your market, and long-term maintenance considerations.
The most common stacks for UK business web applications:
Laravel + Vue.js + PostgreSQL. Excellent developer velocity, strong ecosystem, extensive documentation, widely understood. Laravel's built-in authentication, queue system, scheduling, and testing tools mean less time reinventing infrastructure. Vue.js is approachable and well-suited to applications with moderate interactivity requirements. Hire-ability in the UK is good.
Django + React + PostgreSQL. Python's ecosystem is exceptional for data-heavy applications. Django's admin panel is genuinely useful for internal tooling. React is the dominant frontend framework globally, meaning the largest developer pool. This stack suits applications where data processing, analytics, or machine learning is in scope.
Next.js + Node.js API + PostgreSQL. A JavaScript-throughout-the-stack approach. Next.js handles server-side rendering, SEO, and routing elegantly. Suitable when your team is primarily JavaScript-oriented and when the application has public-facing pages that must perform well in search. The Node.js ecosystem is broad but requires more architectural discipline than opinionated frameworks like Laravel or Django.
Avoid choosing a stack because it is fashionable. Rust, Go, and Elixir have genuine use cases, but the UK developer market for these languages is thin. Maintenance becomes difficult and expensive when your original developer leaves if you cannot find replacements.
A well-structured RFP produces proposals you can actually compare. A vague brief produces wildly varying proposals that tell you more about each agency's assumptions than their capabilities.
Your RFP should include: business context (what you do, who your users are, what problem you are solving); functional requirements (what the system must do); non-functional requirements (performance, security, accessibility, scalability targets); technical constraints (existing systems to integrate with, data to migrate, hosting preferences); delivery expectations (key milestones, launch date, team structure); commercial terms (fixed price vs time-and-materials preference, payment milestones, IP ownership).
London development teams bill at ยฃ500 to ยฃ900 per day for senior engineers. Regional UK rates sit closer to ยฃ350 to ยฃ600 per day. A day rate below ยฃ350 for a senior developer in the UK market is a signal to investigate carefully - either the developer is genuinely junior, or the 'UK agency' is offshoring the actual work without disclosing this.
Request the following when evaluating proposals: references from comparable projects (call them); the actual team who will work on your project (not the pitch team); examples of code from recent work; evidence of a testing culture (ask to see a test suite); and their process for managing scope changes.
Good UX design should be explicitly scoped in your RFP. Many technically proficient development teams produce applications that are difficult for users to learn. A design phase - wireframes, prototypes, usability testing - before full development begins is money well spent and reduces costly late-stage changes.
Project management is where many UK business web application projects lose control of budget and timeline. The following disciplines are not optional for a successful outcome:
Regular sprint reviews with the actual development output. Every two weeks (the standard agile sprint cadence), you should be reviewing working software - not status slides, not wireframes, not promises. If at week six you have not seen a working prototype of your core feature, something is wrong.
A single decision-making authority on the client side. Nothing slows a software project more reliably than a stakeholder committee where every change request requires five approvals. Nominate one person who can make binding decisions about scope, priorities, and trade-offs. That person must be available to the development team within 24 hours during working days.
Explicit acceptance criteria for every feature. 'The booking system works' is not an acceptance criterion. 'A logged-in user can select an available time slot, enter their details, receive a confirmation email, and see the booking in their account history' is an acceptance criterion. Write these before development begins, not after.
A formal change control process. Every new requirement during development must be documented, estimated, and explicitly approved before it enters the sprint. 'Whilst we're at it' is the most expensive phrase in software development. Small additions accumulate and routinely account for 20 to 40 per cent of project cost overruns.
Commissioning bespoke software development is a significant business investment. Treat it with the same governance discipline you would apply to any capital project of equivalent value.
A focused discovery and specification phase typically takes two to six weeks depending on application complexity, the number of stakeholders involved, and how well-defined the business requirements are at the start. Rushing this phase to save time consistently produces problems during development that cost five to ten times as much to fix as they would have cost to address in planning. Treat the planning phase as an investment, not an overhead.
Not necessarily, but you do need technical input in the planning process. A development agency that conducts a proper discovery phase will translate your business requirements into technical decisions and explain the trade-offs in plain English. If you are building a technology product where software is the business, an experienced technical leader in the founding team is valuable. If you are building a tool to support an existing professional services business, a trusted development partner with strong discovery capabilities is sufficient.
A minimum viable product is the smallest version of your application that delivers genuine value to real users and allows you to test your core assumptions. For most web application projects, planning for an MVP first is the right approach. An MVP is not a half-finished product - it is a complete product with deliberately limited scope. It lets you validate your assumptions before committing to full development, gather real user feedback, and adjust course before the bulk of development spend is committed.
Request a non-disclosure agreement before sharing sensitive commercial information. Reputable UK agencies will sign these without hesitation. More practically, be aware that an NDA does not prevent a developer from working in your market segment - it prevents disclosure of your specific confidential information. Your competitive advantage should ultimately come from execution, team, and market relationships, not from keeping your idea secret. The value is in building and shipping, not in the concept itself.
Expect requirements to change. Users discover what they actually need by using working software, not by reading specifications. Build a change management process into your contract from the start: a formal way to document scope changes, assess their impact on budget and timeline, and make informed decisions. Agencies working on fixed-price contracts should have a clear change request process. Those on time-and-materials should provide regular budget burn reports so you can make priority decisions with full visibility of cost.
At minimum: a technical architecture document before build begins; API documentation for any integrations built; a deployment runbook so the application can be maintained or handed over; and an infrastructure diagram showing every component and how they connect. Without this documentation, you are operationally dependent on a single supplier and have no practical ability to switch if the relationship deteriorates. Good development partners treat documentation as a professional obligation, not an optional extra. Agencies that resist producing documentation are signalling that they intend to remain your only option indefinitely.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
