The task you keep repeating,
turned into software.
Orders in a notebook, stock in a spreadsheet, customers scattered between WhatsApp and memory. If something in your business repeats every week, it can be built into a program that does it for you.
No prices here, and not to hide them: no two projects are alike, and naming a figure before knowing what gets built would mean making it up. You get it before we start, closed.
Case study
Finance Module
A personal finance platform: accounts, movements, categories, budgets, goals, recurring movements, bank statement imports, reporting and alerts. Ten sections inside one authenticated system with invitation-only sign-up.
10
working sections in a single authenticated system
506
automated tests, passing without a single failure
25
decision records versioned next to the code
6
full journeys run against the real application
Dependencies point inward
Your business rules sit at the centre and know nothing about the database underneath. It sounds like an engineer's whim and it is not: it is what lets you switch providers without rewriting the app, and test a rule in milliseconds instead of booting half the system.
Presentation
The screens. None of them knows how data is stored.
Application
Who can do what, and in what order. It does not know PostgreSQL exists.
Domain
The money rules. Zero outward dependencies: testable without booting anything.
Infrastructure
The database, the storage, the email. Replaceable by design.
Why it matters to you
- Switching providers touches one folder, not the whole app. You are not locked in to whoever raises their price tomorrow.
- The rules test themselves. A change does not force you to check everything by hand before publishing.
- Six months later you can still find out why something is the way it is, because it is written down. It does not depend on my memory.
The Colombian peso has no cents
Someone logged a 3,800-peso bus fare and the app showed 380,000. The four places that needed to know how many decimals a currency has were asking the browser, and the browser does not always answer the same way.
Look, do not assume
The first three diagnoses were wrong. The fourth came from a log line that said exactly what had happened.
Reproduce before fixing
The bug was forced locally first. Fixing without having watched it break is believing, not knowing.
Two jobs, not one
Fixing the code stops bad data getting in. The rows already stored were repaired separately, with a backup first.
Each currency's scale is now written down in exactly one place, and there is a test named after the problem: «nine thousand pesos are stored as nine thousand, not nine hundred thousand». I tell you this because anyone can show you what worked.
No surprises, same as everything else
There is no published rate because no two projects are alike. What there is, is a closed price before anything starts.
- 1
You tell me what you want solved
What your business does by hand today, what eats your time, what slips through. Half an hour is enough.
- 2
I write down what gets built
A short document: what is in, what is out, how long and how much. If it does not suit you, it stops there.
- 3
It gets built in pieces
You see each piece working before paying for the next. There is never a blind jump of months.
Tell me what you have in mind.
If what you need is solved by something that already exists, I will tell you and save you the project.