Map the current process
Users, steps, delays, errors, duplicate work and the evidence already available.
Business systems, explained before they are built
Turn a messy process into a clear web application plan.
Independent guidance for owners and managers replacing spreadsheets, planning portals, specifying SaaS products or taking control of a legacy system.
Example system map
Customersrequests • documents
Operationsroles • workflows
Web applicationrules • data • history
Paymentsstatus • refunds
Reportingevents • decisions
Process firstbefore screens and technology
Roles & rightswho can see and change what
Data ownershipcode, accounts and exports
Acceptance ruleshow “finished” will be tested
A project route a business can actually follow.
A useful specification describes decisions, exceptions and ownership — not just a list of attractive screens.
Choose the first outcome
Define what the first release must improve and what remains outside it.
Specify roles and exceptions
Permissions, statuses, data, integrations, failures and fallback actions.
Agree ownership and acceptance
Repositories, cloud accounts, documentation, testing and sign-off.
Plan maintenance
Monitoring, support, updates, backups, security and future change.
Start with the type of system.
Each route has different risks, data flows and maintenance needs.
□→□
Customer portals
Accounts, documents, requests, messages, payments and audit history.
∞SaaS MVPs
Value, onboarding, roles, billing, analytics and the operating model.
⌘Business systems
CRM, workflow, internal tools and the choice between ready-made and custom.
⇄Integrations & APIs
What moves between systems, when it moves and what happens when it fails.
↺Legacy takeovers
Code, servers, databases, domains, keys, pipelines and missing documentation.
◇Security planning
Authentication, permissions, updates, backups, monitoring and incident readiness.
Early complexity check
How complicated is the first release?
This tool highlights planning effort. It is not a quotation and does not recommend a supplier.
Guides for expensive decisions.
Clear enough for a business owner, detailed enough to improve a conversation with a technical team.
Website vs web application
Use data, roles, workflows and ongoing operations to decide which kind of project you are actually planning.
Open the guide →How much does a web application cost?
A method based on roles, workflows, integrations, data and uncertainty.
What belongs in a web-app specification?
Processes, exceptions, acceptance and ownership — not only features.
Who should own the source code?
Repositories, licenses, infrastructure, keys and practical access.
Rebuild or modernise?
Compare criticality, tests, data, team knowledge and migration risk.
Control point: Never let the only copy of code, infrastructure access or domain ownership sit inside a supplier account you cannot independently reach.
Editorial controls.
The site is an independent guide, not the previous company and not a hidden development agency.
Method, not mystery prices
Cost content explains drivers and uncertainty rather than pretending a brief is unnecessary.
Protective security content
Security is described to help owners reduce risk, not to enable attacks.
Real or labelled examples
No invented clients, portfolios or “case studies”. Hypothetical examples are marked.
Technology-neutral
The process and business need come before a preferred framework.