A software proposal may recommend a monolith, microservices or a gradual route between them. For a small business, the important question is not which label sounds more modern. It is whether the design supports the required workflows, expected changes and operating capacity at an acceptable cost.
Architecture affects how software is developed, deployed, investigated and recovered. A decision that helps one team release independently can introduce work for another team managing data and failures. Ask the supplier to explain those trade-offs through your actual business processes rather than through a diagram alone.
Understand the distinction without oversimplifying it
A monolithic application is generally delivered as one application unit, although its code can still be organised into clear internal modules. A microservices design separates capabilities into services that can be operated and deployed independently, communicating through defined interfaces.
A monolith and a system of separate services have different deployment and operational implications. Use the distinction to ask about the actual business requirements, team and dependencies rather than treating one architecture as universally preferable. Our software architecture and trade-offs guide provides the related checks.
A monolith need not mean one unstructured file or an application that cannot grow. Microservices need not mean every function becomes a separate service. Ask what the proposed boundaries actually are and how they relate to useful business responsibilities.
Some systems combine approaches. A core application might use a separate service for a distinct integration or workload. The resulting design should still have a clear rationale and operating model, rather than being a collection of components chosen without regard to the team maintaining them.
Start with workflows, expected change and constraints
Describe the journeys the software must support. An enquiry system might receive a request, classify it, assign ownership and record follow-up. A booking service might manage availability, confirmation and changes. Identify which steps must agree on the same business state.
List the changes you can reasonably anticipate. A business introducing new service categories has different pressures from a product with several teams releasing unrelated capabilities. Avoid designing around speculative growth without explaining its likelihood and consequence.
Record constraints on budget, delivery time, support availability and existing systems. Architecture should respond to those constraints openly. A design requiring continuous specialist operations may be difficult to justify when the business has no team or support contract to provide them.
Ask for examples from your process. If a proposal says independent deployment is essential, identify which capability needs it and what problem a shared release would create. This turns a broad benefit into a requirement you can assess.
Examine boundaries and ownership
For a monolithic design, ask how the code will be divided into modules with clear responsibilities. A well-organised application can make future changes easier by keeping business rules and interfaces understandable. Request an explanation of how those boundaries are maintained.
For microservices, ask why each service is separate and who owns it. A boundary based on a stable business capability can be easier to reason about than one based on an arbitrary screen or database table. Check how changes crossing several services are coordinated.
Autonomous services can support independent changes, but also introduce wider operational complexity. Independent components still need a coherent overall system, including communication, observability, permissions and reliable handling of failure. Our architecture and technical debt guide provides the related checks.
Find out what happens when an owner is unavailable or a supplier changes. Documentation, interfaces and deployment rights matter in either design. The business needs a maintainable arrangement rather than a system whose boundaries exist only in one developer's memory.
Ask how data remains consistent through a workflow
Choose an important business transaction and ask the team to trace it through the proposed design. For a booking, show how availability is checked, a reservation is recorded, and the customer receives confirmation. Identify what counts as completion.
Then examine partial failure. If one stage succeeds and the next is unavailable, what state does the business see? Who resolves it? A customer should not receive an unexplained promise simply because one component accepted a request.
In a distributed design, network communication and separate data ownership can require explicit coordination. Ask how repeated events, delayed updates and conflicting changes are handled. The supplier should explain the business outcome as well as the technical mechanism.
In a single application, shared data can simplify some operations, but it still requires sound rules and testing. A monolith is not automatically immune to duplicate submissions, background-job failures or external integration problems. Compare the demonstrated behaviour under the same scenarios.
Compare deployment and testing responsibilities
Ask how a change travels from development to live use. Record the review, test environment, approval and recovery steps. A simple application can still need disciplined releases, while separate services need checks that their interfaces remain compatible.
For microservices, establish how the team tests a journey spanning several components and manages version differences. One service passing its own tests does not prove that the complete customer route works. Request evidence from the integrated process.
For a monolith, ask whether the test structure helps isolate a change and whether releases affect unrelated functions. Clear internal design and useful automated checks can reduce uncertainty without splitting the application into independently operated services.
Review rollback in business terms. Reverting code may not undo a data migration or a completed external action. The release plan should explain how the team handles those cases and preserves information needed to investigate them.
Evaluate scaling against a demonstrated need
Define the workload using realistic volumes, peaks and response expectations. A campaign, batch import or reporting task may create a different load from ordinary daily use. Ask which part of the system is likely to become constrained and what evidence supports that view.
Do not assume that splitting services automatically produces a faster customer experience. More communication can introduce latency, and a poorly designed data query can remain expensive in either architecture. Assess representative journeys under agreed conditions.
Ask how the proposed solution scales and what that costs. Independent scaling may be useful when workloads differ substantially. A simpler deployment may be sufficient when the workload is modest and predictable. The decision should connect capacity with evidence.
Include growth options without demanding that every future possibility be implemented now. A supplier can document thresholds that would trigger further work, such as a measured bottleneck or a need for independent ownership. That is more useful than an unsupported claim that the system is future-proof.
Count the operating work, not just development effort
List the production components and responsibilities. Include hosting, credentials, monitoring, backups, deployments and incident response. More services can create more places where configuration and recovery need attention, even when each service's code is small.
Ask how an enquiry failure is investigated. Can the support team connect one customer request with the relevant processing record? Who receives an alert, and which owner decides the next action? Useful observability is about resolving a business problem, not merely collecting logs.
Compare total costs over an appropriate period. Infrastructure charges are only part of the picture. Include support, testing, maintenance, developer onboarding and the effort required to keep interfaces and dependencies current.
Identify the minimum operating capability each option requires. A design can be technically sound yet unsuitable for the people and budget available. Make those responsibilities explicit before the business commits to the proposal.
Request a decision record and a practical evolution route
Ask the supplier to document the chosen approach, alternatives considered, reasons and important limitations. A concise decision record helps a future team understand why the system looks the way it does. Include assumptions that should be revisited if circumstances change.
Prefer an evolution plan tied to evidence. Improving module boundaries, removing a bottleneck or separating a genuinely independent capability can be sensible steps. Rebuilding everything into microservices solely to change the architecture label is a weaker business case.
Giraffe Digital's digital strategy service connects business tools with customer journeys and operating needs. Architecture discussions should support that same result: dependable workflows, clear ownership, justified complexity and a system the business can afford to change and maintain.
Frequently asked questions
How should we understand the distinction without oversimplifying it?
A monolithic application is generally delivered as one application unit, although its code can still be organised into clear internal modules. A microservices design separates capabilities into services that can be operated and deployed independently, communicating through defined interfaces. A monolith and a system of separate services have different deployment and operational implications. Use the distinction to ask about the actual business requirements, team and dependencies rather than treating one architecture as universally preferable. Our software architecture and trade-offs guide provides the related checks. A monolith need not mean one unstructured file or an application that cannot grow. Microservices need not mean every function becomes a separate service. Ask what the proposed boundaries actually are and how they relate to useful business responsibilities.
How should we examine boundaries and ownership?
For a monolithic design, ask how the code will be divided into modules with clear responsibilities. A well-organised application can make future changes easier by keeping business rules and interfaces understandable. Request an explanation of how those boundaries are maintained. For microservices, ask why each service is separate and who owns it. A boundary based on a stable business capability can be easier to reason about than one based on an arbitrary screen or database table. Check how changes crossing several services are coordinated. Autonomous services can support independent changes, but also introduce wider operational complexity. Independent components still need a coherent overall system, including communication, observability, permissions and reliable handling of failure. Our architecture and technical debt guide provides the related checks.
How should we compare deployment and testing responsibilities?
Ask how a change travels from development to live use. Record the review, test environment, approval and recovery steps. A simple application can still need disciplined releases, while separate services need checks that their interfaces remain compatible. For microservices, establish how the team tests a journey spanning several components and manages version differences. One service passing its own tests does not prove that the complete customer route works. Request evidence from the integrated process. For a monolith, ask whether the test structure helps isolate a change and whether releases affect unrelated functions. Clear internal design and useful automated checks can reduce uncertainty without splitting the application into independently operated services. Review rollback in business terms.
How should we evaluate scaling against a demonstrated need?
Define the workload using realistic volumes, peaks and response expectations. A campaign, batch import or reporting task may create a different load from ordinary daily use. Ask which part of the system is likely to become constrained and what evidence supports that view. Do not assume that splitting services automatically produces a faster customer experience. More communication can introduce latency, and a poorly designed data query can remain expensive in either architecture. Assess representative journeys under agreed conditions. Ask how the proposed solution scales and what that costs. Independent scaling may be useful when workloads differ substantially. A simpler deployment may be sufficient when the workload is modest and predictable. The decision should connect capacity with evidence.
How should we request a decision record and a practical evolution route?
Ask the supplier to document the chosen approach, alternatives considered, reasons and important limitations. A concise decision record helps a future team understand why the system looks the way it does. Include assumptions that should be revisited if circumstances change. Prefer an evolution plan tied to evidence. Improving module boundaries, removing a bottleneck or separating a genuinely independent capability can be sensible steps. Rebuilding everything into microservices solely to change the architecture label is a weaker business case. Giraffe Digital's digital strategy service connects business tools with customer journeys and operating needs. Architecture discussions should support that same result: dependable workflows, clear ownership, justified complexity and a system the business can afford to change and maintain.
