Design Document as a Service
In many projects the technology is settled before requirements and costs are known. We reverse the order: first the implementation plan with architecture, timeline and a binding price, then the code.
Anyone building a house has ideas, wishes and a budget. What is usually missing is a reality check and a concrete plan for getting there in the best way possible.
Because not every good idea can be built sensibly. Some things are not technically feasible, some are needlessly expensive, and some can be solved far better another way. That is what an architecture practice does. It reviews the ideas, weighs up the options and turns them into a plan that holds.
Questions only come up late, often too late:
- Runtime environment, release cycle and SLAs
- Critical user journeys and expected latencies
- Integration with existing systems
And those are just a few examples.
In complex software projects, this step is missing surprisingly often. The technology decision is already made before requirements, dependencies and costs are even known. Building starts immediately, planning happens on the side.
The architecture practice for your software project
Posedio takes on exactly that role. We bring our experience from many complex software projects and look for the best and most efficient solution for your requirements, independent of any vendor.
To do that, our architecture team sits down with you, understands your requirements and designs a concrete implementation plan from them. We call that plan a Design Document. It is the basis for everything built afterwards. It describes the golden path through your project, the technologies involved, the architecture decisions, and a transparent framework for costs, resources and timeline.
It is not a static specification locked in for the whole project. Requirements change, assumptions turn out to be wrong, and implementation feeds new insights back. So the document grows with the project.
Changes are cheaper because the architecture allows for them from the start. The target state is defined, the dependencies are known, and the trade-offs made are deliberate and documented. That lowers the risk of fundamental course corrections, the kind that force whole components to be rebuilt or demand costly workarounds for decisions that turned out to be wrong.
You get a complete implementation plan for your software project, with transparent costs and resources based on your binding requirements.
How your Design Document comes about
Five steps, from the first session together to the approved version.
- 01
Workshop
Together with you, we gather the requirements and work out first solution approaches.
- 02
Stop or go
A short decision point. Both sides check whether working together makes sense. You or we can end the project here.
- 03
First draft
We turn the findings from the workshop into a first version of the Design Document.
- 04
Review
In a joint session we walk through the document and take on your feedback.
- 05
Approval
The revised version is approved by you and by us.
What a Design Document costs
| Service | Price |
|---|---|
| Creating the Design Document | 3,000 euros net |
| Workshop, drafting, review session and final version | included |
| If you commission the implementation from Posedio | free of charge |
| What it saves you in wrong decisions and rebuilds | priceless |
If you decide to build with us, the cost of the Design Document is waived in full.
The Design Document is yours
You can build it with us, with your existing provider or with your own team. It commits you to nothing, and in turn we do not automatically take on every project. That is exactly what keeps our assessment independent.
Frequently asked questions
What does a Design Document cost?
3,000 euros net. If you decide to build with Posedio, the cost is waived in full.
What is included in the price?
Workshop, drafting, review session and the final version. Review rounds incur no additional cost.
Do I have to commission the implementation from Posedio?
No. You can implement the Design Document with us, with your existing provider or with your own team. It is explicitly not a commitment to Posedio.
What does a Design Document contain?
A complete implementation concept with architecture and tech stack, a phased timeline, a binding price, and named and assessed risks.
How does the process work?
We start by understanding your problem, in an initial conversation or a workshop. If the task fits our expertise, we work out the solution that suits you from the full solution space and record the alternatives we discarded along with the reasoning. We then refine the draft together until the overall concept is coherent and you sign it off.
How long does it take?
The actual work usually takes one to two working weeks, provided we get timely access to your subject-matter contacts and feedback on our drafts. More complex undertakings, or a large number of stakeholders, can take longer. After the initial conversation we can commit to a firm timeframe.
What happens if we turn out not to be a good fit after the workshop?
There is a decision point right after the workshop. Both sides assess whether working together makes sense — you or we can end it there.
Is a Design Document the same as a requirements specification?
No. Our Design Document answers not only what we build, but why. It lays out the context, makes alternatives and their consequences visible, and thereby gives you a basis for decisions. The essential parameters — architecture, technology stack, milestones, risks and costs — are set out bindingly. New insights are incorporated through a traceable change management process. Acceptance criteria are governed separately in the contract.
Your Design Document starts with a conversation
We discuss your project and work out together whether a Design Document is the right next step.
Request a Design DocumentThis is what a Design Document looks like
- Client
- Muster Handel GmbH
- Written by
- Posedio
- Version
- 1.0
- Status
- APPROVED
- Scope
- ~15 weeks
- Confidentiality
- Confidential
Overview
Muster Handel runs its order processing on a twelve-year-old, license-based on-premise system. The goal of the project is to replace it with a cloud-native, open platform that scales elastically during seasonal peaks, is highly available, and no longer incurs license costs.
Stakeholders: e-commerce leadership (sponsor), IT operations, customer service and logistics. Benefits: eliminated license costs, higher availability during promotion days, and significantly shorter change cycles.
Rough timeline: around 15 weeks to go-live, followed by handover to the internal team.
The Requirements
2.1 Business Requirements
Goal — What are we trying to achieve? A central platform that accepts orders, reconciles inventory, manages shipping, and keeps customers informed about status. Includes self-service dashboards for customer service.
Backstory — Why is this needed? The legacy system costs around €120,000 per year in license fees, goes down under load on promotion days, and only allows changes through week-long vendor release cycles.
Context — Who uses it, and how? Around 150 internal users from customer service and logistics, roughly 50,000 orders per day with up to 5x peaks on promotion days.
2.2 Necessary Maturity Levels
Maturity settles two things upfront: who the solution is built for, and what quality standard the code has to meet.
Functional
In ascending order of demand; one level is fixed.
Rationale: Customer service works with it every day and end customers check their order status after signing in. It has to be production-ready, but not built for anonymous access from the open internet.
Code Maturity
| Solution | Targeted quality |
|---|---|
| Just has to work | Quick wins, no further consideration |
| Quick first version, extensible later | Quick wins with some foresight |
| Product with a long lifespan | Extensible and maintainable by us |
| Code is handed over to the client ✓ | 100% maintainable and extensible |
2.3 Nonfunctional Requirements
What a system is supposed to do is only half the requirement. How well it does it shapes the architecture at least as much. We therefore capture and prioritise the key quality goals, using ISO/IEC 25010:2023 as a checklist and reference. That way we avoid costly wrong decisions and size the system exactly right: neither overengineered nor undersized.
You decide what matters most. Quality attributes often pull against each other: more security costs speed, more flexibility costs maintainability. Prioritising them settles upfront which side wins when they collide.
2.4 Risk Assessment
| Risk | Impact | Likelihood | Mitigation | Owner |
|---|---|---|---|---|
| Data migration from the legacy system is incompletely documented | HIGH | NORMAL | Migration PoC & data audit already in Phase 0 | Posedio |
| Business department hard to reach for requirements clarification | NORMAL | LIKELY | Fixed workshop slots, a named product owner | Muster Handel |
| Cutover falls on a promotion day | HIGH | UNLIKELY | Cutover scheduled outside peak, tested rollback plan | joint |
| Resource bottleneck on the client side, particularly specialists in the network team | HIGH | LIKELY | Request capacity early with a concrete time window, have management grant it priority, create visibility within the project and keep personal contact with the team | Muster Handel and Posedio |
| Departments that hand over tasks or responsibilities to the solution do not support the implementation | NORMAL | NORMAL | Involve those affected in workshops early, address the benefit for each stakeholder explicitly, engage the sponsor actively | Sponsor Muster Handel |
| Denial-of-service attacks on publicly reachable endpoints bring the application down | HIGH | LIKELY | Rate limiting and WAF at the gateway, defined autoscaling and load limits, load tests against the agreed capacity targets, incident process for an attack | Architecture Posedio |
| Compromised credentials or overly broad permissions allow unauthorised access to data | HIGH | NORMAL | Central identity management with MFA, least privilege and regular recertification, secrets exclusively in the secret store, log and review all access | Security Officer Muster Handel |
| Vulnerable dependencies in libraries or container images reach production unnoticed | HIGH | LIKELY | Automated dependency and image scanning in the pipeline, build fails from a defined severity upwards, maintain a software inventory, defined patch process with response times | Operations and SRE Posedio |
Planned Timeline
Work packages bundled into five phases over 15 weeks. Go-live is a hard deadline.
| Phase | Work Package | Interval |
|---|---|---|
| P1 Design & Setup | Design Doc, environments, IaC scaffolding | W1–2 |
| P2 Platform Foundation | CI/CD, cluster, observability stack | W3–5 |
| P3 Core Services | Orders, Inventory, Shipping | W6–10 |
| P4 Migration & Cutover | Data migration, go-live (hard deadline) | W11–13 |
| P5 Hypercare & Handover | Stabilisation, SRE handover, knowledge transfer | W14–15 |
The Solution
4.1 Implementation
Event-driven services for Orders, Inventory and Shipping behind a central API gateway. Customer service gets self-service dashboards, end customers get automatic status notifications. The production-ready core is built by P3, with further features following iteratively.
4.2 Architecture
Cloud-native on Kubernetes, fully defined as Infrastructure as Code. Loosely coupled services communicating over an event bus, managed PostgreSQL as the database, and observability across everything.
The architecture and flow diagrams are the core of the plan. They show which components are built from scratch and which are bought in or taken from the open source ecosystem, how the solution fits into the existing systems, which interfaces connect it, and what provisions are needed, for business continuity or legal requirements for example. The goal is a system that meets every requirement while being as simple as possible to develop and operate.
4.3 Tech Stack
| Technology | Purpose | Why this choice |
|---|---|---|
| Kubernetes | Orchestration | Open and portable instead of proprietary PaaS lock-in |
| Terraform | Infrastructure as Code | Reproducible, versioned, auditable |
| PostgreSQL | Database | Proven and license-free — replaces expensive DB licenses |
| Kafka / NATS | Event backbone | Decoupled, scalable services |
| OpenTelemetry · Prometheus · Grafana | Observability | Open standard instead of an expensive APM license model |
| Keycloak | IAM / Login | Open-source identity management, no vendor lock-in |
4.4 Cost Implications
The alternative (lift-and-shift of the licensed product into the cloud) would be cheaper to implement, but keeps the license costs and vendor dependency permanently. Recommendation: the open rebuild — higher one-time investment, clearly lower running costs.
Glossary
| Term | Description |
|---|---|
| NFR | Nonfunctional Requirement — a quality requirement such as availability or security |
| IaC | Infrastructure as Code — infrastructure described declaratively and under version control |
| SLO | Service Level Objective — a measurable target for availability or latency |
| Cutover | The switch from the legacy system to the new one |
| Hypercare | An intensively supported stabilisation phase right after go-live |
Change Management
| Date | Changed by | Comment |
|---|---|---|
| 2026-02-10 | Posedio | First draft after workshop |
| 2026-02-24 | Posedio | NFR prioritisation & risks aligned with the business department |
| 2026-03-03 | Muster Handel | Approval v1.0 |
Let's talk about your project
Avoid expensive wrong turns and awkward compromises, and find a solution for your IT project that holds up over time. Request your Design Document today.
Request a Design Document