Six services that work together.
Most engagements start the same way: somebody has to write down how things run today and what the new solution has to do. From there we work out how the systems exchange information and which data moves between them. When the work reaches delivery, we do it and hand it over so that the next person can carry on.
Six services, one person accountable. The same analyst takes the work from written requirements to a working solution, and each service can be ordered separately or one after another.
Six services you can order separately or in sequence.
System and business analysis
When the way work runs lives only in people's heads, it cannot be ordered, tested or handed over. Analysis turns it into a document a developer, a contracting authority or an auditor can work from.
- Requirements documentation and user stories
- AS-IS and TO-BE processes, BPMN diagrams
- Acceptance criteria and a decision log (ADR)
- Automation pre-analysis: process mapping and screening of candidates
System integration
Data is copied by hand, the reports do not reconcile, and nobody is quite sure where the original lives. Before an interface is built, you have to agree where data originates and who owns it.
- Data-flow mapping and a shared vocabulary
- API specifications (OpenAPI 3.x) and interface descriptions
- A map of dependencies and risks
- Integration pre-analysis before development or a tender
Software development
The work has been thought through and the decision has been taken. What is needed now is someone to take it from requirements to a working solution and then hand it over so that the next person can carry on.
- Database-backed web applications
- API and integration builds
- Automated tests, deployment in a CI/CD pipeline
- Technical documentation and handover
System replacement and data migration
The new system has been chosen and the old one has to be switched off. The hardest part is not configuring the new one, it is proving that exactly what was supposed to move actually moved.
- Source-to-target data mapping
- Data-quality rules and cleansing decisions
- Test migrations and data reconciliation
- A cutover plan with a rollback plan
Software testing
Acceptance turns into an argument when what was agreed was a set of wishes rather than checkable criteria. Testing starts from requirements and ends with someone being able to say "accepted" in writing.
- Test strategy and test plan
- Test cases straight from requirements and acceptance criteria
- Running acceptance testing, and defect management
- Test process review and recommendations
Terms of reference and procurement preparation
Bids become comparable only when every bidder is reading the same description. Writing that description is a job of its own, and it is done before the tender is published.
- Feasibility study and comparison of solution options
- Terms of reference or technical specification for a tender
- Evaluation criteria and bid comparison
- Independent oversight during delivery
The centre of our work is data models, interfaces and the flow of data between systems. Where the result has to be handed on to a developer, into a tender, or to an auditor.
Security is part of every engagement, not a separate line on the invoice.
Security awareness reaches requirements, processes and data flows from the start: who gets access to what, what is sensitive, what is logged, and what happens when something goes wrong. These questions are cheap to ask while requirements are being written and expensive to ask after go-live.
In delivery the same idea becomes a way of working. Authentication and permissions from the start, input validation, secrets kept out of the code, dependencies kept current, and logging done so that afterwards you can tell what happened. For attack testing and penetration testing we bring partners in, and we agree that before the work starts.
If what is in front of you right now is a client's security questionnaire or a security requirement in a tender, we wrote about that separately: Turvalisus äriettevõttes: mida teha enne, kui audiitor või klient küsib (article in Estonian).
Concrete deliverables, not just slides.
Auditable. Transferable. Reusable.
Every engagement ends with tangible artefacts that can be handed to a developer, leadership, an auditor or the next analyst — without anyone having to start over.
-
D.01
Requirements documentation
Business, functional and non-functional requirements in one place: security, performance, availability, compliance.
FormatsDOCXMDCONFLUENCE -
D.02
AS-IS / TO-BE business processes
Current and target state in BPMN, with bottlenecks, control points and the impact of the change.
FormatsBPMNDRAW.IOPDF -
D.03
User stories and acceptance criteria
User stories with Gherkin-style acceptance criteria — ready for the sprint backlog and test automation.
FormatsMDJIRAGHERKIN -
D.04
Dataflow diagrams
How data moves between systems and processes, with classification and sensitivity tagging (PII, retention, owner).
FormatsDRAW.IOMDPDF -
D.05
APIs and integrations
OpenAPI 3.x contracts, authentication, error scenarios, quotas, versioning.
FormatsOPENAPIMDPOSTMAN -
D.06
Threat model at requirements level
A STRIDE-based review at the level of requirements and data flows: abuse cases, attack-surface map, controls mapped to requirements. Part of the analysis — not a pentest or a security audit.
FormatsMDDRAW.IOPDF -
D.07
Risk analysis
Risks with impact/likelihood ratings, mitigations and owners — in a form an auditor can read.
FormatsXLSXCONFLUENCE -
D.08
Compliance map
Requirement → control → evidence: DORA, NIS2, GDPR, ISO 27001, internal policies.
FormatsXLSXMDPDF -
D.09
Decision log (ADR)
Architecture Decision Records: what was decided, why, which alternatives were considered, which trade-offs were made.
FormatsMDSHEETS -
D.10
Test strategy and test cases
Test levels, coverage logic and test cases linked back to requirements and acceptance criteria.
FormatsXLSXMDJIRA -
D.11
Data mapping and quality rules
Source-to-target field mapping, transformation and quality rules, reconciliation checks.
FormatsXLSXMDSQL -
D.12
Terms of reference and tender description
Scope, requirements, evaluation criteria and assumptions, in a form that makes bids comparable.
FormatsDOCXMDPDF
Deliverables are handed over in editable formats. PDF only means the next person starts from zero.
Four steps. No surprises.
Message and first discussion
Describe in a message what you want to solve. We go through the situation and tell you clearly how we can help.
Written scoped proposal
Concrete scope, timeline, assumptions, and price. One page, in clear language.
Sprint-based delivery
Short iterations, visible outputs. Status report at the end of every sprint, decision log kept continuously.
Handover and follow-up support
We hand documentation over to your team or the next partner. Support for 4–8 weeks after handover.
The key questions before we start working together
Will you sign an NDA before we talk in detail?+
How does pricing work?+
How does security get into your work?+
How is the volume of work agreed?+
How quickly can you start?+
What languages do you work in?+
Does ordering one service commit you to ordering the next?+
Describe your situation in one message.
Write down what exists and what is missing. We talk the scope through and send a written offer. We reply within one working day, and the first discussion is free.