Dragen

Dragen / What we do / Internal systems

The spreadsheet half the company runs on.

Almost every company has one file or one mailbox that everything stops without. No change history, no permissions, and nobody who understands all the formulas. We build what should be there instead.

What we usually find

The process works because three people know how to work around it. Data sits in a spreadsheet nobody can lock, in a mailbox one person can open, and in a system it has to be retyped out of. Nobody designed this - it accumulated, because it worked.

The cost appears in no report, because it is spread across hours of retyping, mistakes caught at the last moment, and decisions taken on numbers that were already stale.

What we build

Workflow with permissions and history

Who changed what, when, and on what basis. Not for control - so that a decision taken a year ago can be reconstructed.

Dashboards somebody actually looks at

One screen of numbers that require a response, rather than ten charts that prompt nobody to do anything. We design from the question "what will you do when this number goes up?".

Integrations

With the accounting system, with mail, with whatever you already run. This is usually more work than the interface, and usually where projects come apart.

The stack we work in

Python and FastAPI on the server, PostgreSQL for storage, Docker to run it, automated tests as a condition of acceptance rather than an extra. We match it to what you can maintain - if your team writes .NET, building in Python is the wrong decision regardless of what we prefer.

Questions

What people ask first.

Why build when a product exists?
Usually you should not. If a product does what you need we will say so and stop there. Building makes sense where the process is genuinely yours, and where bending the company to fit a tool would cost more than the tool.
What about the systems we already have?
That is usually the larger half of the work. We connect to what you run - database, API, mail, files. If a system has no API we say so during estimation, because it changes the scope.
Who maintains it afterwards?
You or us, but it has to be settled before we start rather than at handover. We leave the repository, tests and run instructions so that anyone can take it over.

Tell us which process eats your day.

We answer within one working day - including when the answer is that software is the wrong tool for it.

Get in touch