Digital Products & Engineering
Custom Software
We turn the rules your business actually runs on into software you own, with code and documentation another team could pick up.
The problem
Our operation has outgrown its spreadsheets, and no packaged product fits the way we work.
Nobody plans to run a company on a fragile spreadsheet. It happens gradually: a few macros, a shared drive, a workaround only one person understands. The day that person is away, work stalls.
The instinct is to sketch screens and ask for quotes, but screens are the easy part. The expensive surprises sit in unwritten rules: who approves what, how exceptions get handled, when a record locks.
Ownership is the other trap. When the repository, cloud accounts, and documentation stay with the vendor, leaving gets harder every year.
You may recognize this
- Two reports show different totals for the same month.
- A critical process depends on one employee's memory.
- You can't reach the source code of software you already pay for.
How we work
Build-or-buy pass
We look for code that shouldn't be written: commodity functions go to existing products, and scope narrows to the workflows that set you apart.
Domain and data model
With the people doing the work, we capture entities, state transitions, and exceptions in a data model. Architecture decision records preserve the reasoning.
Vertical slice first
One real workflow goes live through every layer first, testing the architecture while changes are still cheap.
Access, audit, and handover
Role-based permissions, an append-only audit log, and KVKK-aligned retention rules ship in the first release. CI/CD and staging guard each deploy, and migrations are rehearsed on masked data.
What we deliver
- Build-or-buy assessment
- Data model and written business rules
- Architecture decision records
- Role matrix and audit logging
- Tested software with a CI/CD pipeline
- Repository, accounts, and runbooks in your name
How we measure
- Lead time for changes, which shows how fast the software can follow the business.
- Work done outside the system, because a returning spreadsheet signals lost trust.
- Time for a new developer to ship a first change, the honest test of maintainability.
A made-to-order manufacturer
Illustrative scenario: A made-to-order manufacturer prices jobs in a spreadsheet, and the costing logic lives in one estimator's head. Those rules go into a data model, and only the quoting workflow ships first. Inventory and planning stay in the existing ERP, which the new software reads over an API.
Common questions
Who owns the code?
You do. The repository and cloud accounts are set up in your name at the start, so you have access throughout and nothing to negotiate at the end.
Can you give us a fixed price?
For a defined slice, yes. A whole system described in a few pages would only get a guess, so we price discovery and the first slice, then the rest by module.
What happens to our existing data?
Legacy data is almost always messier than expected. We map fields, write migration scripts, and rehearse before cutover. You decide what moves and what gets archived.
Before we work together, let's think together.
Requests are answered by the founder.