I
Business systems
The internal software a company runs on — order handling, scheduling, reporting, whatever the spreadsheet has quietly become. Built to be operated by your staff, not by us.
Internal systemsWorkflowsReporting
IT · Software development · Integrations · Cyprus
Services
Four kinds of business software, and the handover package that ships with all of them.
01 — What we build
Four kinds of work
Business software rather than consumer apps. Unglamorous systems that a company depends on and that have to keep working.
II
Integrations & APIs
Getting two systems that were never designed for each other to exchange data reliably, including what happens when one of them is down. Most integration work is really error handling.
APIsData exchangeError handling
III
Automation
Removing the manual steps that exist because somebody once did them by hand. We look for the ones that are frequent and boring, not the ones that are interesting to build.
Batch jobsRulesScheduling
IV
Migration & maintenance
Moving data off a system that has to be retired, and maintaining what exists. Neither is glamorous; both are where the risk usually sits.
MigrationUpgradesSupport
05 — The boundary
What we do not do
Four things we decline, so nobody wastes a call finding out.
No fixed price on vague scope
A fixed price on an undefined scope is either padded or a future argument. We scope first, then price.
No hostage code
No licence-back, no escrow, no undocumented dependency on us. You can always leave.
No resource leasing
We deliver work, not headcount by the month. Renting developers by the day is somebody else’s business model.
No build-anyway
If existing software does the job, we say so, even though that ends the conversation.
02 — Approach
How we work
Small increments, visible early, and no reveal at the end.
Phase 01
Understand
What the process actually is, watched rather than described. Specifications written from descriptions build the wrong thing accurately.
Phase 02
Slice
The smallest useful piece that can go live on its own. If nothing can, the scope is wrong and we say so.
Phase 03
Build
Working software in short cycles, in your hands throughout. Surprises are found while they are still cheap.
Phase 04
Hand over
Code, documentation, tests and a runbook. Then we are available, not necessary.
In detail
What "handed over" actually means
Four things that ship with every project. Agreed at the start, so they never become a negotiation at the end.
Handover 01 · Code
The repository, with history
Not a zip file. The full repository with its commit history, so the next developer can see why something is the way it is.
RepositoryHistoryOwnership
Handover 02 · Decisions
Why, not just what
A short written record of the architectural decisions and the options rejected. This is the document that saves the most time later and is skipped most often.
ArchitectureTrade-offsRejected options
Handover 03 · Tests
Proof it works, repeatably
Automated tests and instructions to run them. Without tests, the next change is a gamble and everyone starts being afraid of the code.
AutomatedRunnableDocumented
Handover 04 · Operations
Deploy, monitor, roll back
How to release it, how to tell it is healthy and how to undo a bad release at two in the morning.
DeploymentMonitoringRollback
Handover package · standardActive
Repository
Yours
From day one
Docs
Included
Never extra
Source & historyIncluded
Decision recordIncluded
Automated testsIncluded
RunbookIncluded
Standard scope — extended where a system warrants it
04 — FAQ
Clearly answered
Who owns the code?
You do, from the first commit. The repository is yours, the history is yours, and there is no licence back to us hiding in the contract.
What if we want to move to another developer?
Then the handover package should make that unremarkable. If leaving us is painful, we did the job badly.
Do you charge extra for documentation and tests?
No. They are part of the work, not an upsell. A system without them is unfinished, not cheaper.
Will you maintain what you build?
If you want us to. Many clients run it themselves, which is the point of the handover package.
Do you take over someone else’s codebase?
Yes. We start with a written assessment of what is there before promising anything — inherited systems reward honesty about their state.
Which markets do you serve?
Registered in Cyprus, working across the EU, in English and German.
Let’s talk
A system to build, inherit or finally retire?
Describe the process and what currently goes wrong. If a spreadsheet or an off-the-shelf tool would do it better, that is what you will hear.