Business process automation
Document flows, approval chains and reporting moved off spreadsheets and mailboxes into an auditable system with roles, history and exports.
solutions
Enterprise solution work, described as method rather than as claims
2GO Systems OÜ does not publish client names, logos or delivery statistics. What follows is how we would approach four recurring situations, so a prospective client can judge the method before there is any commercial relationship.
capability areas
Where this work concentrates
Four areas that recur across custom development, consulting and modernisation engagements.
Security and data-protection engineering
Threat modelling, access control design, secrets management, encryption at rest and in transit, and the technical measures a GDPR Article 32 assessment asks about. Advisory and implementation — we hold no certification and issue none.
Platform and environment consolidation
Several inherited environments reduced to one described in code, with parity between staging and production and a rebuild that can be demonstrated.
Interface and integration layers
A documented API in front of systems that were never designed to be integrated, so partners and internal teams stop depending on database access.
worked approaches
Four situations and how we would take them on
These are illustrative scenarios written by us, not case studies. No engagement, client or result is described or implied.
S-01 · illustrative scenario
A system nobody wants to touch
Situation. A revenue-carrying application has one remaining maintainer, no test suite and a deployment nobody can reproduce. Every change is a negotiation about risk.
How we would approach it
- 01Characterise the system: dependency inventory, data profile, deployment archaeology, incident history.
- 02Put a safety net in first — a smoke suite and a rebuildable environment — before changing any behaviour.
- 03Extract an interface, then move capability behind it in slices, keeping the old path live until it carries nothing.
What that would aim at. A system that can be changed by more than one person, with the migration measured in slices rather than in a single cutover date.
S-02 · illustrative scenario
Integration by spreadsheet
Situation. Orders, invoices or master data move between systems by export, e-mail and manual re-entry. Errors are found in month-end reconciliation, not when they happen.
How we would approach it
- 01Model the actual flow as it happens today, including the exceptions people handle informally.
- 02Define contracts between the systems, with idempotency, retry and a dead-letter path for anything that cannot be processed.
- 03Add reconciliation reporting so a discrepancy surfaces the same day, with the record that caused it.
What that would aim at. An integration whose failures are visible and attributable, rather than absorbed by people re-keying data.
S-03 · illustrative scenario
A cloud bill nobody can explain
Situation. Environments were created by hand over several years. Staging and production have drifted, nobody is certain what is safe to delete, and the invoice grows without a matching change in load.
How we would approach it
- 01Inventory what exists and map each resource to a service and an owner.
- 02Redefine environments as code so a rebuild is demonstrable, then rebuild staging from that definition.
- 03Retire what nothing references, and put cost attribution and alerting in place before optimising anything.
What that would aim at. Environments that can be rebuilt from a repository, with spending attributable to a service rather than to a mystery.
S-04 · illustrative scenario
Personal data in a system designed before GDPR
Situation. A working system holds personal data with no documented retention, no deletion path and access controlled by shared credentials.
How we would approach it
- 01Map the data: what is held, where it came from, who can reach it and how long it stays.
- 02Design the technical measures — access control, encryption, logging, retention and erasure paths — and implement them incrementally.
- 03Produce the engineering evidence a controller needs for Article 30 records and an Article 32 assessment.
What that would aim at. A system whose data-protection posture can be described accurately by the people accountable for it. We advise and implement; we do not certify, and legal assessment remains with the client and their counsel.
Why there are no case studies here. A named client, a metric or an offer of contactable references asserts something a reader cannot check and we cannot publish without that client’s written agreement. Until such an agreement exists, this page describes method only. Ask us in a scoping call and we will tell you directly what we have and have not done.
reference architecture
The shape we design towards
Most engagements converge on a similar structure: one entry point, services that own their data, asynchronous work isolated from request handling, and a platform layer that can rebuild the whole thing. Select a component to see what we mean by it.
Clients
Edge
Application
Data
Platform
Domain services
Business logic split along domain boundaries, each service owning its data and publishing events rather than sharing tables.A reference topology we design towards, shown to make the conversation concrete. It is not a diagram of any client system, and the components in any real engagement are chosen against that client’s constraints.