Practice

desca.dev is the working name of a two-person infrastructure consulting practice that has been shipping production systems since 2014. We are a lower-case studio: no marketing department, no growth metric, no quarterly OKR. The practice is structured the way a small architectural firm is structured — engagements are long, the work is documented, and the principals are the ones who write the code that the principals signed off on.

We do not have a sales pipeline. We have a waitlist of three to six months and a reading list that we maintain on the wall of the office in Bairro Alto. Engagements begin with a site visit, a closed-room reading of the existing system, and a written letter of opinion. Only after the letter is exchanged and signed do we open an editor.

The work that follows the letter is, in nine cases out of ten, smaller and quieter than the client expected. We rewrite a single subsystem; we replace a queue; we delete more code than we add. Where we do build new, we build it the way a tenured carpenter joins a cabinet — for a long second life, with the joinery exposed for whoever inherits the room.

The practice's name — desca — is Portuguese for the fishing creel, the woven basket a fisherman wears at the small of his back. It is not branding. It is the literal description of the job: small, sturdy, carried for a lifetime, cleaned out at the end of each day.

The Stack

We work in a deliberately small toolkit. The list below is not a manifesto and it is not an endorsement — it is a record of what is open in the editors of this office, today, on a Tuesday afternoon. We change tools when the work changes, not when the tool gets a press release.

1. 01. PostgreSQL 16, with logical replication and a strict policy on schema migrations — one PR per migration, written by the principal, reviewed by the other principal, never automated.
2. 02. Go 1.22 for daemons; Rust 1.78 where the daemon must hold a lock for longer than a heartbeat. We do not litigate the choice in either direction.
3. 03. NATS JetStream for queues. We have replaced Kafka with NATS in three of the last five engagements and have not regretted it.
4. 04. Caddy 2 at the edge. Automatic TLS is not a luxury feature; it is a baseline.
5. 05. Bash, in 2026, for any glue script under 200 lines. Anything longer becomes a single-purpose Go binary checked into cmd/.

What is missing from the list is intentional. We do not run Kubernetes for any client below 50 services; we do not adopt a service mesh as a default; we do not build microservices when a single binary will outlive the consultant. The most expensive line in any engagement is almost always the line of YAML written eighteen months ago by someone who has since left.

Cases We've Worked

What follows is a redacted summary of three engagements from the last eighteen months. Names are omitted by agreement. The shape of the work is what matters.

Case 01 — A failing payments ledger

A medium-volume European fintech (ten million daily transactions) had a ledger that double-charged at exactly the hours when its operators were asleep. We were called after the third on-call rotation in a row had ended in a manual SQL repair. The engagement lasted seven weeks. We rewrote the ledger as an append-only event log with periodic snapshotting; we did not touch the rest of the application. We deleted 14,000 lines of compensating logic that the team had accreted over four years. The ledger has not double-charged in twenty months.

Case 02 — The queue that ate the warehouse

A logistics platform had a single Redis-backed work queue that, under load, would silently drop scheduled jobs the moment Redis evicted a key. The symptom was missing manifests at 4 a.m. local time on the day of a peak. We replaced Redis-as-queue with NATS JetStream, kept Redis for caching, and added a single observability rule: every job that enters the queue emits an opening receipt, every job that leaves emits a closing receipt, and a daily reconciliation job alerts when the two ledgers diverge by even one entry. The reconciliation job has alerted twice in fourteen months — both times correctly, both times caught before the warehouse was on the floor.

Case 03 — A search index that lied

A consumer marketplace had a search index that, after eighteen months of incremental updates, had silently drifted out of agreement with the source-of-truth catalog. The drift was small enough that it was below the noise floor of the QA team and large enough that it was costing measurable revenue at the long tail. We did not add a new index. We added a daily diff job, written in 240 lines of Go, that compared every catalog row to its index entry and produced a single CSV report. The report fits on a printed page. It is read on Mondays. The drift is now zero.

How We Write Software

The method is not a methodology. It is six habits, written down here for the first time because a junior engineer asked, in a recent engagement, if we had a guide. We did not. We do now.

• Read the failing system for one full working week before writing a single line. This is non-negotiable. The bug is rarely where the report says it is.
• Write the migration first, in plain English, on paper. If the migration cannot be summarised in three short paragraphs, the migration is not yet understood.
• Prefer deletion. Every PR begins with the question: can this be solved by removing code? The answer is yes more often than the industry believes.
• Write commits as if the next reader is a tired senior engineer at 02:30 on a Sunday. They are.
• Choose the boring framework. Boring frameworks have already failed in public for ten years and the failure modes are documented.
• Leave the room cleaner than you found it: one closed bug for every two opened, every week, no exceptions.

We do not write design documents in the canonical sense. We write letters. A letter is addressed to a specific reader (usually the principal engineer of the client team), is written in the second person, and ends with a single question. The question is the contract for the next conversation.

Field Notes

Eight things from the last quarter of work, in no particular order, written in the field-notebook idiom that the office uses. None of these is a thesis. They are observations.

• The phrase eventually consistent is, in production, almost always being used to mean silently inconsistent. The two are not the same. A human must be on the eventual side of the consistency.
• A staging environment that does not receive at least 1% of production traffic is a museum of last quarter's bugs. Mirror the load or close the museum.
• If the on-call rotation is shorter than seven days, the on-caller has not yet seen the system's diurnal rhythm. Lengthen the rotation, not the runbook.
• The single most common defect we have removed in the last two years is a retry without backoff. The second most common is a backoff without jitter.
• If a query is slow, run EXPLAIN twice — once with the actual production statistics, once with the staging statistics. The two plans diverge more often than the industry expects.
• A queue with no maximum depth is not a queue, it is a memory leak with a fancy name.
• The only safe time to deploy a database migration is the time at which the on-call engineer is awake and undistracted. There is no other safe time. Calendar around the human.
• The best operational dashboard fits on one printed page in 11pt monospace. If it does not fit, the dashboard is not yet a dashboard, it is a dataset.

Letters from Clients

We do not solicit testimonials. Once a year, in late November, we ask a former client whether they would be willing to write a paragraph — not for a marketing page, but for our office wall. Three of them, with permission, are reproduced here. Names are abbreviated by request.

"They came in, sat in the back of the war-room for a day and a half without saying a word, then handed us a single sheet of paper that began with the sentence: your problem is not your queue, it is your trust in your queue. We argued with them for an afternoon. They were right. We have not had a 4 a.m. page in eleven months."

"Most of what desca.dev shipped for us was a deletion. They removed roughly a quarter of our payments code and the system became, against my expectations, both faster and easier to reason about. I have stopped being surprised by the result; I have started being surprised that the rest of the industry adds first."

"They write letters. Actual letters. The first one I received from them ended with a single question and I was annoyed because I did not have a good answer. Six months later, having answered the question, I realised the entire engagement had been about the question, not the code. The code was the receipt."

The letters are pinned to the office wall, in chronological order, in a single column — the same measure as this column. The wall is the only marketing channel the practice maintains.