DEV Community: Christian • ancer

What a Year of Real Use Changed About My App

Christian • ancer — Wed, 23 Sep 2026 09:00:00 +0000

Version 1 of this app was used for real exactly once. One evening, last year, for about three hours.

I was in the room. I didn't touch the keyboard, and I only answered questions when the session would otherwise have stopped. What I did instead was write things down: every hesitation, every time the person driving it went back on something they'd just done, every question from the room that the screen couldn't answer.

That notebook is, almost line for line, the changelog of version 2.

The app is Rueda de Actos, a Windows desktop app for the Filà Ligeros — one of the groups that take part in the Moros y Cristianos festival in Alcoy, Spain. Once a year it hands out participation in five festival events, eleven slots each, following a rotating turn that has to stay fair from one year to the next. The session happens in a meeting room, projected on a wall, with the board watching.

What I deliberately didn't do was ask

I could have sent a list of questions the next morning. It would have been faster and it would have produced a worse list.

If I'd asked what's missing, I'd have got three or four reasonable answers, because that's what the question invites: a considered opinion about the app in the abstract. The list I actually came home with had fifteen items on it, and the ones that mattered most were things nobody would have volunteered — in the moment they didn't register as missing features. They registered as this is just how it is.

The notebook had two columns. What the person did, and what they seemed to expect would happen. Only the gap between those two things was worth anything. A pause before a click is a gap. Going back to fix something a different way than the app offered is a gap. Somebody in the room asking a question that the screen was already answering, badly, is a gap.

Asking gets you opinions. Watching gets you requirements.

Here's what came out of it.

1. A closed event has to be re-openable

About ninety minutes in, on the fourth of the five events, somebody noticed that a name in event two shouldn't have been there.

Version 1 had exactly one answer for this: Restore by Event, which reloads the snapshot taken just before that event was verified. It works perfectly. It also erases events three and four, which had taken forty minutes and a fair amount of discussion to settle.

So it didn't get used. The correction was written on paper and applied later. Which means that from that moment on, the app was no longer the record of what had happened — the paper was.

Reopening a single event is easy to describe and slightly more interesting to implement than it looks, because closing an event doesn't only fill cells. It rotates people. Everyone who took part moves to the back of the queue, and that rotation is the entire fairness guarantee the app exists to provide.

The obvious fix — restore each person's previous queue number — is wrong. Their old neighbours have moved on:

// Someone pulled out of a reopened event does NOT get their old num_rueda
// back: the people who did go out are no longer ahead of them, and everyone
// has moved up a place. What they get is their relative position — behind the
// first of their former predecessors who still hasn't gone out. Number 7, with
// number 3 already rotated away, comes back as 6, which is what they're owed.
lista.splice(idxActual, 1)

let destino = 0
for (let i = idxPrevio - 1; i >= 0; i--) {
  const anterior = lista.find(
    (p) => p.nombre === state.ordenPrevioReabierto[i] && !haSalidoEsteAño(p)
  )
  if (anterior) {
    destino = lista.indexOf(anterior) + 1
    break
  }
}

lista.splice(destino, 0, persona)
reasignarNumerosRueda()

ordenPrevioReabierto is just the list of names as it stood in the snapshot taken before that event closed. If the snapshot is gone, the person goes last among those who haven't been out yet — a worse placement, but the reopen still happens. Refusing to correct an error because a backup file is missing would be solving my problem, not theirs.

A year later, this is the feature I'd point at if somebody asked what watching bought me. It wasn't a missing button. It was a case where the app's only recovery mechanism was so expensive that the user quietly stopped using the app instead.

2. An event that wasn't full was showing as full

Skipping an event already existed in version 1. That wasn't the problem.

The problem was afterwards. A skipped event and one that closed with eight of eleven slots looked exactly like a full one — five identical green cards across the top, all reading as done.

That's not sloppiness in the view layer, it's information being destroyed at close time. The per-event counter gets clamped to the limit when an event is verified, because that's the flag for "played":

// Slots actually covered when each event closed; null = not closed yet.
// This needs its own record because `contadores` can't tell you: on close it
// gets pinned to the limit to mark the event as played, so a skipped event or
// one verified half-empty is indistinguishable from a full one.
plazasCubiertas: { escuadra1: null, escuadra2: null, diana1: null, diana2: null, diana3: null },

With that in place the card can tell the truth:

// Played, but without filling all 11 slots: skipped, or verified with fewer
// people. The rota carries on either way, so the card is the only place this
// is recorded.
function actoIncompleto(acto: ActoName): boolean {
  const cubiertas = appState.plazasCubiertas[acto]
  return actoFinalizado(acto)
    && cubiertas !== null
    && cubiertas < appState.limitePorColumna[acto]
}

It now goes amber and says Skipped or Incomplete, with the real count — 8/11 — and the status bar warns at the end of the rota how many closed short.

This matters more than a colour, because that history is the input to next year's turn. An event closed with eight people is not the same fact as one closed with eleven, and version 1 was quietly writing down the second when the first had happened. Reality doesn't fill every slot. Software that assumes it will ends up storing a slightly false year, then reasoning from it.

3. The spreadsheet they already had

Version 1 started from a JSON file. I know that file was fine, because I built it myself, out of their spreadsheet, on my machine.

Which is the whole problem. An app whose first screen needs a data migration performed by its developer is not a tool that group owns. It's a tool I own and let them use.

They had a spreadsheet. Every association has a spreadsheet.

So version 2 imports and exports both Excel and JSON, in both directions — and, the part that actually took the work, accepts a sheet somebody typed by hand. The only hard requirement is a column called Nombre.

Headers are matched after normalisation, and both the visible header and the internal field name are accepted:

// No accents, no case, whitespace collapsed: the header the app writes has
// accents and the one the user types may not, and "Género" and "genero" have
// to be the same column.
function normalizar(texto) {
  return String(texto == null ? '' : texto)
    .normalize('NFD')
    .replace(/\p{Diacritic}/gu, '')
    .replace(/\s+/g, ' ')
    .trim()
    .toLowerCase()
}

Values are read the same way — H/M for gender, X or Sí for a checkbox, Cad. for an expired license, because that's what people actually put in cells. But there's one decision in there I'd defend harder than the rest:

const SI = new Set(['si', 'sí', 's', 'x', 'true', 'verdadero', '1'])
const NO = new Set(['no', 'n', 'false', 'falso', '0'])

// Unrecognised values come back untouched instead of becoming "No": the main
// process validates afterwards, and it's better for the user to see what they
// typed wrong than for the app to decide for them and silently change a fact.
function aSiNo(valor) {
  const bruto = texto(valor)
  if (bruto === '') return ''
  const clave = normalizar(bruto)
  if (SI.has(clave)) return 'Sí'
  if (NO.has(clave)) return 'No'
  return bruto
}

Being lenient about input and being lenient about meaning are different things. Reading x as yes costs nothing. Reading an unrecognised value as "No" would let a lenient importer write a false fact about a person, and nobody would ever find out.

The reciprocal fix was less glamorous: in version 1 the Excel the app exported could not be imported back. It generated a file it couldn't read. Nobody had complained, because nobody had tried, but a format that only goes one way isn't an export — it's a printout.

4. Nobody types accents in front of a room

The single most repeated moment of the evening was somebody looking for a name in a table of ninety-six rows, scrolling, while the room waited.

Version 2 has a search box. The whole feature is about fifteen lines, and the only part that matters is that it doesn't ask for precision:

// The names come in from the imported file in caps and with accents, so
// without normalising, searching "jose" wouldn't find "JOSÉ".
function normalizar(texto: string): string {
  return texto.normalize('NFD').replace(/\p{Diacritic}/gu, '').toLowerCase()
}

Two smaller decisions came from the same three seconds of watching. Results are ordered by where the match starts, so people whose name begins with what you typed come first — when you type a first name, that's who you mean, even if the same string shows up inside somebody else's surname. And the highlight is sliced out of the original string, not the normalised one, so the accents and capitals survive on screen:

return hallados.slice(0, MAX_RESULTADOS).map(({ indice, persona, pos }) => {
  const nombre = persona.nombre || ''
  return {
    indice,
    persona,
    antes: nombre.slice(0, pos),
    coincide: nombre.slice(pos, pos + termino.length),
    despues: nombre.slice(pos + termino.length),
  }
})

None of this is clever. It's the kind of thing that gets skipped because it isn't a feature, it's a detail — and then it turns out to be the difference between finding a person in two seconds and scrolling a table in front of an audience.

5. Closing the app shouldn't cost you the evening

This one didn't come from a hesitation. It came from the app being closed with unsaved work in it.

The data model here is deliberately strict: the app always boots from the saved database, never from the working session. Save is the only point that consolidates anything. That's a real feature — it means closing without saving is a clean undo of the entire evening, which is exactly what you want after a session that went sideways.

It also means an accidental close is catastrophic, and an accidental close is not a hypothetical. It happened.

You can't fix that by relaxing the rule, because the rule is the feature. So every change to the working session also writes it somewhere separate:

// Single point every change to the working session passes through, so it's
// also where "there's something pending Save" gets marked.
function guardarEnSession(): void {
  ipc.saveSessionPersonas(state.listaPersonas)
  state.cambiosSinGuardar = true
}

That lands in its own SQLite table, next to the consolidated one:

CREATE TABLE IF NOT EXISTS session_data (
    key TEXT PRIMARY KEY,
    value TEXT NOT NULL,
    timestamp TEXT
);

And Settings → Load temporary version (session) brings it back, with both timestamps shown side by side so you can see what you're choosing between. Closing the app now also asks, offering Save and exit / Exit without saving / Cancel — and if the save fails, it doesn't exit.

The general shape of this: if you make a strict rule about when data is committed, you owe the user a way back from the one case where that rule hurts. Not a softer rule. An escape hatch, clearly labelled as one, sitting outside the normal flow.

What I didn't build, and why

Fifteen items in the notebook. Not fifteen features. Some of the best decisions of version 2 were the ones I talked myself out of:

Two people editing at once. This never came up as a request; it came up as a could it. The session has exactly one person driving, in a room, on purpose. That's what makes the outcome authoritative. Multi-user doesn't improve that evening, it dissolves it.
Cloud sync or cloud backup. The app backs up its database locally every thirty minutes, which protects against nothing if the machine dies. The honest answer to "what if the laptop breaks" is export the file and put it somewhere else, and I ship that instead. Adding a server would also undo the entire offline-first argument the app is built on.
A configurable number of events and slots. Genuinely the most tempting one, and it came from me rather than from the room — the generalisation itch. Five events, eleven slots, in that fixed order, is what this group does. Making it configurable buys a hypothetical second customer and charges every screen in the app a layer of indirection to get there.
A general undo stack. Reopening an event covers the case that actually occurred. Ctrl+Z over a rotating queue is a much larger idea wearing a small idea's clothing.
Auto-update. It checks nothing and connects nowhere. Updating means running the new installer over the old one, and that is the whole story.

Every one of those makes the app more capable in the abstract and worse at the single evening it exists for. Saying no to them is not restraint or minimalism, it's the same design work as saying yes to the other five — done in the direction nobody gives you credit for.

Version 1's job was to produce the list

The uncomfortable part is how cheap every one of these fixes was. A field that stores what the counter destroys. A normalise call. A second table. A placement loop that took an afternoon.

I could not have specified any of them up front, and I don't think a longer analysis phase would have got me there. I wrote version 1 from the rules of the rota — slots, rotation, squads, veterans, licenses, penalties — and every one of those rules was implemented correctly in version 1. It was a correct application. The list above isn't in the rules. It lives in the gap between the rules and one evening in a room in Alcoy.

So "a year of real use" is doing some work in that title, and I should be precise about it: one session run live, and twelve months of that session's result being the thing people actually consulted. Both halves produced findings. The evening produced the hesitations; the year afterwards produced the ones you only notice when you go back to the data and it doesn't say what happened.

Between them they produced a better requirements document than any process I could have run beforehand, and the cost was sitting still and writing things down.

If there's something to take from it, it isn't watch your users — everybody says that and nobody schedules it. It's narrower: version 1 doesn't have to be complete. It has to be good enough to be used for real, once, in the actual conditions. Then you have to be in the room, and you have to keep your hands off the keyboard.

Designing a UI That Gets Projected in Front of a Room

Christian • ancer — Wed, 16 Sep 2026 09:00:00 +0000

Almost every interface decision I make assumes a private screen. One person, their own monitor, their own data in front of them. It's such a safe assumption that it never gets written down anywhere.

For the last few months I've been building a Windows desktop app called Rueda de Actos, for the Filà Ligeros — one of the groups that take part in the Moros y Cristianos festival in Alcoy, Spain. Its job is to hand out participation in five festival events, eleven slots each, following a rotating turn that has to stay fair from one year to the next.

It breaks that assumption completely.

The app runs once a year, in a meeting room, projected on a wall, with the whole board watching. One person drives it. There are ninety-six names in the table on screen, and a good number of them belong to people sitting in that room.

Every interesting design decision in this app came out of that one sentence.

The room is the spec

Put the scenario next to the usual mental model and the assumptions fall over one by one.

The usual assumption	The actual session
One user looking at the screen	One user driving, a room reading over their shoulder
The data is about other people	The data is about the audience
A mistake costs a few seconds	A mistake happens in front of everyone it affects
You can use the app again tomorrow	The session happens once a year

None of that is exotic. It's a projector and a meeting, which describes a fair amount of internal software. The difference here is that the rows are the audience — this is a group of neighbours and friends deciding who marches in which squad, and the tool is standing in the middle of it.

So the brief stopped being "make this efficient to operate" and became something closer to "make this safe to project".

The block is public. The reason is private.

Two things can make a person ineligible: unpaid dues and a standing penalty. Both are recorded per person. Neither one appears anywhere in the table.

They live in the individual record, behind the pencil icon on the row, as two toggles next to the license status. That record opens for one person at a time, and in practice it gets opened when nobody has a reason to look.

What the table shows instead is that the cell can't be clicked. That's it.

The reason this works is that a blocked cell is deliberately ambiguous. Three different rules produce it, and they all render identically:

// Behind on dues, or carrying a penalty.
const blockedByStatus = (person.unpaidDues || person.penalty)
  && event === activeColumn && !assignedThisYear

// Already taking part in another event this year.
const blockedByAnotherEvent = !state.allowMultipleEvents
  && hasAnyEventThisYear(person) && !assignedThisYear && person[event] == null

// Already did this same event in an earlier edition.
const blockedByRepeat = !state.allowRepeatEvent
  && event === activeColumn && !assignedThisYear && person[event] != null

// One class. Three reasons. The cell never says which.
classes['cell-blocked'] = blockedByStatus || blockedByAnotherEvent || blockedByRepeat

And that class is a single flat pattern, with nothing attached to it:

td.cell-blocked {
  background-image: repeating-linear-gradient(
    -45deg, transparent 0 5px, rgba(100, 116, 139, .13) 5px 6px
  );
  cursor: not-allowed;
  pointer-events: none;
}

The room sees that the rules were applied. The room does not learn who owes money.

The temptation I had to talk myself out of was the tooltip. On any other desktop app I'd have added title="Blocked: unpaid dues" without thinking — it's helpful, it's cheap, it's what a good interface does. Projected, it's the worst feature in the product: the same private fact, on a half-second delay, rendered wherever the mouse happens to be resting, at wall size.

Worth being precise about where the line sits, because it isn't "hide every status". The avantcarga license — the paperwork some members need for certain events — is right there in the open, as a small coloured card next to each name and as a running count in the header: 32 valid, 13 expired, 51 none. Nobody minds. It's an administrative fact about a document.

Money and penalties are a fact about a person, in a room full of people who know them. That's the line, and it isn't a technical one. It came from asking what would be uncomfortable to have on a wall, not from a data classification exercise.

Everyone has to stay oriented, not just the operator

In a normal app, only the user needs to know where they are. Here, thirty people are following along without touching anything, and every question they can't answer for themselves becomes an interruption: wait, which event are we on? how many are left? is that one full?

So the state of the session is permanently on screen, not tucked behind the current interaction:

Five cards across the top, one per event, each showing 8/11 and a men/women split (H 8 M 0), with a fill bar. The event in progress is the blue one.
The active column is tinted down the entire height of the table, so a row halfway down the list still reads as belonging to the current event.
A status line along the bottom: how many people are in the rota, which event is in progress, and whether the squad has locked to a gender.

One small detail I like more than it probably deserves. When an event closes, its per-gender counters are reset internally, so leaving them on the card would show a confident H 0 M 0 for an event that had just filled eleven slots. The card swaps them for a state instead — Completed, Skipped, Incomplete, Pending verification — and only shows numbers while they still mean something.

Nobody would catch that in a code review. Projected, a wrong number on a wall gets a question from the third row, and the session stops while somebody explains that the zero doesn't mean what it says.

If you cover something, let them move it

When the eleven slots fill, a verification modal opens listing the eleven people, with a checkbox for squad leaders and an × to remove anyone who shouldn't be there. It's the moment the room is paying most attention.

It also covers about eleven rows of the table underneath — which is exactly when somebody asks whether so-and-so already went out last year.

On a private screen the answer is trivial: close the dialog, look, open it again. In front of a room, that means throwing away a selection you just made while eleven people wait for you to rebuild it.

So every modal in the app can be dragged out of the way:

const INTERACTIVE = 'button, a, input, select, textarea, label, [contenteditable]'

function onPointerDown(e) {
  if (e.button !== 0) return
  const target = e.target
  if (target.closest(INTERACTIVE)) return

  // The handle is the header. Small dialogs have no header, so anything
  // non-interactive works there.
  const header = contentEl.value?.querySelector('.modal-header')
  if (header && !header.contains(target)) return

  measureBase()
  pointerStart = { x: e.clientX, y: e.clientY }
  offsetStart = { ...offset.value }
  dragging = true
  contentEl.value?.setPointerCapture?.(e.pointerId)
  e.preventDefault()   // without this, dragging selects the dialog's text
}

Two things in there exist only because of the room.

The first is that check against INTERACTIVE. Dragging from a button would make the checkboxes in that verification list less than perfectly reliable to click, and a mis-click during verification is the one mistake you cannot make quietly.

The second doesn't appear in that snippet: every offset is clamped against window.innerWidth and innerHeight before it's applied, so the dialog can't be dragged past the edge of the screen. This is a kiosk-shaped desktop app — no browser chrome, no page scroll, nothing to rescue a window that left the viewport. Get that wrong and the operator is closing a modal they can no longer see, blind, in front of everybody.

The position also resets to centre on every open, rather than remembering where the last dialog was left. Where you dragged the previous dialog says nothing about what the next one is covering.

Interrupt for changes, not for confirmations

The app has one dialog system, and the rule that decides how a message appears turned out to be a single line:

// A notice is a dialog that closes itself and expects no answer.
const isNotice = computed(() =>
  dialog.timer > 0 && !dialog.showConfirmButton && !dialog.showCancelButton
)

If there's nothing to answer, it isn't allowed to take the screen. Saved, 12 records imported, Exported to XLSX, Event reopened — corner of the screen, no backdrop, a thin bar draining to show how long it stays, gone in two seconds. The app underneath keeps working the whole time.

Dimming an entire projected wall to announce "Saved" is absurd once you've watched it happen. It was also covering the modal that was in the middle of closing behind it.

The interesting case is the one that still blocks.

The squad rules say an event locks to a gender once six of the eleven go the same way. When that happens the app doesn't just note it — it un-assigns everyone of the other gender from the event, which rewrites rows the room is actively reading.

That started life as a corner notice. It was wrong. The toast slid away after two seconds, the table simply changed, and people were left wondering what the operator had done.

It's now the one message in the app allowed to take the whole screen: centred, no backdrop click, no Escape, and a single Understood button somebody has to press before the session moves on. It names the rule that fired — Men's event — and says plainly that the women have been un-assigned.

The rule I ended up with: interrupt when the screen changed underneath the room, never to confirm something the operator did on purpose.

At three metres, colour is the interface

Nobody in the fourth row is reading a table cell. They're reading colour and position, and only leaning in when something looks off.

So colour carries real information, and it's the only part of the visual design with a strict budget:

Green — assigned in the current edition.
Hatched grey — unavailable, reason unstated.
One tint per past year — 2023 amber, 2024 yellow, 2025 blue, and so on. You can see how long ago someone last did an event without reading a single number.
Bold year — that person was a squad leader that year.
A small coloured card beside the name — license valid, expired, or missing.

Everything else is grey. There is no colour in this UI that doesn't mean something, which is less a matter of taste than of bandwidth: the moment you use a tint for decoration, the room starts trying to decode it.

The honest caveat: those license cards are colour-only, three images that differ in nothing but hue, with a title carrying the exact status. That would not pass an accessibility review, and it's on the list. The rest of the palette is redundant — every tinted cell also contains the year as text, and blocked cells carry a hatch pattern as well as a fill — but the cards genuinely aren't, and writing this up is what made me notice.

None of this was in the requirements

Here's the part that bothers me a little.

Every decision above is small and cheap. Not painting two fields. One CSS class covering three cases. A pointerdown handler with an early return. A boolean choosing corner over centre.

And not one of them was in anything I was given. The brief was the rules of the rota — slots, rotation, squads, veterans, licenses, penalties — and every one of those rules is in the app, correctly. You could implement the entire specification, pass every test, and still ship something that quietly puts a member's unpaid dues on a wall in front of them.

They came from watching the previous version being used. Not from a demo and not from a call: somebody had been running this session for years, and the shape of that evening — the projector, the questions from the room, the window that had to be closed to check something — was the real requirements document. It just wasn't written like one.

I don't have a repeatable process for extracting that, and I'm suspicious of anyone who claims one. The closest thing I have is a question I now ask early, before any of the interesting technical questions: where will this be running, and who else can see the screen?

Context of use is a functional requirement

We're fairly disciplined about non-functional requirements when they have familiar names. Performance, accessibility, security — those get budgeted for.

Where the screen is doesn't have a familiar name, so it gets skipped. And when it's skipped, what you ship is an interface that is entirely correct and still fails on the one night it's used, because you built for a desk and it ended up standing in front of a room.

The rota is fair either way. The maths doesn't care where it runs. But the whole point of building this was that the group could watch the reasoning happen and stop having the argument — and that only works if the screen shows exactly what the room is entitled to see, and not one field more.

Building Offline-First Desktop Software in 2026

Christian • ancer — Wed, 09 Sep 2026 09:00:00 +0000

Every new app is drawn with a server in it.

Accounts, an API, sync, a subscription tier. It gets decided before anyone asks the question that actually matters: where will this run, and who is standing in front of it?

For the last few months I've been building a Windows desktop app called Rueda de Actos. It's a custom tool for the Filà Ligeros, one of the groups that take part in the Moros y Cristianos festival in Alcoy, Spain. Its job is to hand out participation in five festival events, eleven spots each, following a rotating turn that has to stay fair year after year.

It makes zero network calls. Not one. No accounts, no sync, no telemetry, no update check.

That isn't nostalgia and it wasn't a shortcut. It's the answer the context gave.

The room decides the architecture

Software gets used somewhere, and that somewhere usually has more to say about your stack than any benchmark does.

Here is the somewhere: a room, a projector, the whole board sitting around a table, and one person driving the app while everyone watches the screen. It happens once a year. The wifi in that building is whatever it happens to be that night.

Run a cloud app against that scenario and count the failure modes:

The connection drops on the one night of the year the tool is needed.
Members' personal data leaves the building to sit on somebody else's server.
The tool stops working the day a subscription lapses, or the day I stop maintaining it.

None of those are exotic. They are the ordinary price of having a server, and normally you pay it gladly, because you get sync, multi-user access, remote access and painless updates in return. In this room you get none of that back. There is one user, one machine, and one session a year.

So the server came out. What's left is a database file on the computer of the person running the meeting.

The stack

Layer	Choice
Shell	Electron 31
UI	Vue 3 (Composition API) + Bootstrap 5
Data	SQLite via `better-sqlite3`
Build	Vite
Tests	Vitest
Packaging	electron-builder → NSIS installer
Logging	electron-log, to a local file

Nothing exotic. The interesting part is what the renderer is allowed to do. It runs with nodeIntegration off and contextIsolation on, so its entire access to the machine is whatever the preload script decides to hand it:

// electron/preload.js
contextBridge.exposeInMainWorld('api', {
  getPersonas: () => ipcRenderer.invoke('db:getPersonas'),
  savePersonas: (data) => ipcRenderer.invoke('db:savePersonas', data),
  importXLSX: (path) => ipcRenderer.invoke('import:xlsx', path),
  exportJSON: (data, path) => ipcRenderer.invoke('export:json', data, path),
  // ...
})

The UI is a web app that cannot touch the filesystem or the database. It can call the handful of functions the preload hands it, and nothing else. Every one of them is validated on the other side before it reaches SQLite. Removing the server does not mean removing the boundary — it means the boundary moved inside the process.

What disappears when you delete the server

Accounts and authentication. Physical access to the laptop is the authentication.
Sync and conflict resolution. There is one writer. There is never a merge.
Recurring cost. Nothing to pay, nothing to renew, nothing to migrate when a provider changes its pricing.
Attack surface. No listening port, no endpoint, no token to leak, no dependency on my uptime.
The privacy conversation. Not because it was answered well, but because it stopped applying.

That last one was the part the client actually felt. "Where do the names end up?" — "On your computer. They never leave it."

Three problems move in instead

Deleting the server doesn't simplify the project. It relocates the difficulty.

1. Backups are your job now

There is no nightly dump on somebody else's infrastructure. So the app makes its own: a full SQLite copy every 30 minutes, keeping the last ten.

function performBackup() {
  const timestamp = new Date().toISOString().replace(/[:.]/g, '-').slice(0, 19)
  database.backupToFile(path.join(backupDir, `rueda-ligeros-${timestamp}.db`))
  rotate(backupDir, MAX_BACKUPS)   // newest ten stay, the rest are unlinked
}

performBackup()
setInterval(performBackup, 30 * 60 * 1000)

better-sqlite3 exposes SQLite's own online backup API, so this is a consistent snapshot rather than a file copy taken mid-write.

Worth being honest about what this protects against: those copies live on the same disk as the original. They save you from "I just broke the data", not from "the laptop died". The second one has a different answer, further down.

2. Migrations run on a machine you will never see

There is no maintenance window, no staging environment, no rollback button, and nobody to call. The user double-clicks the new version and the schema has to be correct by the time the window appears.

So the schema is versioned, and the app migrates itself on startup:

function runMigrations(db, log) {
  const currentVersion = getSchemaVersion(db)   // from a metadata table
  const pending = migrations.filter(m => m.version > currentVersion)

  for (const migration of pending) {
    db.transaction(() => {
      migration.up(db)
      setSchemaVersion(db, migration.version)
    })()
    log.info(`Migration v${migration.version} applied: ${migration.description}`)
  }
}

Each migration is a { version, description, up } object in an ordered array, each one runs inside a transaction, and a throw stops the chain instead of leaving the database half-converted.

That structure earned its keep on migration 3, which normalised the event assignments out of the personas table into a persona_actos child table. SQLite's answer to dropping columns is create-copy-drop-rename, which is well documented and looks harmless:

Create the new child table.
Read the old assignments.
Rebuild the parent table without the old columns.
Insert the assignments into the child table.

Get steps 3 and 4 the wrong way round and you lose data silently. With foreign_keys = ON, the DROP TABLE personas in step 3 fires an implicit DELETE, which cascades through ON DELETE CASCADE and empties the child table you just carefully filled. No error. No warning. An empty table, and a version number claiming the migration succeeded.

The comment explaining that ordering is now four lines long and sits directly above the code. When a migration runs on a stranger's machine, in a building you're not in, the day before the tool is needed, there is no second attempt.

3. Distribution is a person carrying a file

No auto-update. Not even a version check — a version check is a network call, and the whole premise was that there aren't any. The electron-builder config has no publish block and never will: there is nowhere to publish to, and nothing to check against.

New version means a new installer, run over the old one, data preserved. That is the entire update story.

And then there's SmartScreen. The installer isn't code-signed, so Windows greets a non-technical user with a blue full-screen panel that says "Windows protected your PC" and hides the button that runs it anyway behind a More info link. To a developer that's an inconvenience. To the person installing it, that dialog reads as "this is a virus", and the software has failed before it ever opened.

There are two options: buy a certificate, or explain. A code-signing certificate is a recurring cost, and even with one, SmartScreen reputation takes downloads to accumulate — which an app with a single-digit user count will never get. So the build script is written to sign automatically the day a certificate exists, and until then the answer is documentation: one line in the install guide, and a heads-up to the person who will click the button, before they click it.

It's an unsatisfying answer. It's also the honest one, and pretending the dialog doesn't exist would have been worse.

The data has to be able to leave

With no server, there is no "your data is safe with us" to offer. What you can offer instead is that nothing is trapped.

Everything imports and exports in both directions, as XLSX and as JSON. Import accepts the spreadsheet the group was already keeping — a hand-made one is fine, as long as there's a name column. Export writes a file that goes on a USB stick, into an email, or onto another machine.

That's also the real backup story. The half-hourly copies protect the session; the export is the one that survives the hard drive. And it's the answer to the question every custom-software client should ask and rarely does: what happens to us if you disappear? The data is a spreadsheet. Somebody else can pick it up.

Testing replaces the operations you don't have

No error tracking, no logs streaming back to me, no ability to hotfix anything. Whatever ships is what runs until somebody tells me otherwise.

What's left is testing before the fact: close to 400 tests covering the turn rotation, the eligibility rules, validation, the migrations and the import/export round trip, running on every build of the installer. Plus electron-log writing to a local file, so that when something does go wrong there's something concrete to ask the user for.

That trade is easy to underestimate. Server-side, you can be wrong for twenty minutes. Here, being wrong means being wrong for a year.

Offline-first isn't a step back

The reflex is to read a local desktop app as what we used to do before we knew better. Sometimes that's exactly what it is. Here it isn't.

Everything the cloud would have added to this project — sync, accounts, remote access, seamless updates — is worth nothing in a room with one machine and one session a year. Everything it would have introduced — a connection that can fail, a bill that can lapse, personal data on somebody else's disk — lands squarely on the night it matters most.

Picking an architecture is not picking the most current option. It's picking the one that still works under the real conditions of use.

The wifi in that room can do whatever it likes. The app opens.

The First Version Is Just The Beginning

Christian • ancer — Wed, 29 Jul 2026 09:00:00 +0000

Releasing a piece of software feels like reaching the finish line. After weeks or months of planning, writing code, fixing bugs and polishing details, clicking the "Publish" button is a satisfying moment. But the more products I build, the more I realize that a release isn't the end of the journey. It's simply the point where the product stops being shaped only by the developer and starts being shaped by the people who actually use it.

Before a launch, every design decision is based on assumptions. You can test your application, ask for opinions and imagine different workflows, but there's a limit to how much you can learn in isolation. Real users always find unexpected ways to use a product. They notice friction you had stopped seeing, ask questions you never considered and often reveal problems that only appear outside your own development environment.

One thing I've learned is that software rarely improves because of one huge update. More often, progress comes from dozens of small refinements. A shortcut that saves a few seconds. A button that's easier to find. A clearer error message. A better default setting. None of those changes deserves a headline on its own, but together they have a significant impact on how the product feels after weeks or months of use.

Feedback plays an important role in that process, although not always in the way people expect. Feature requests are useful, but they are only one type of feedback. Sometimes the most valuable comments aren't asking for something new—they're describing a moment of confusion or explaining why a workflow didn't behave as expected. Those observations often highlight opportunities to simplify the product rather than expand it.

That's the mindset I've tried to keep while working on Convertim. Since its release, the objective hasn't been to add features as quickly as possible. Instead, I've focused on understanding how people use the application, improving existing workflows and being selective about what deserves to become part of the product. Every new feature increases the cost of maintenance, documentation and testing, so saying "not yet" is often as important as saying "yes."

This approach isn't the fastest way to build software, but I believe it leads to better products in the long run. A tool that stays focused is usually easier to understand, easier to maintain and more enjoyable to use than one that tries to solve every possible problem. Growth is important, but clarity is what keeps a product useful over time.

Final Thoughts

Version 1.0 isn't the destination. It's the first opportunity to learn from real users and real workflows. The goal isn't to ship as many updates as possible, but to make each one meaningful. Looking back, I think that's what building software is really about: continuous improvement, thoughtful decisions and accepting that the first version is only the beginning.

Every Dependency Has a Cost

Christian • ancer — Sat, 25 Jul 2026 09:00:00 +0000

One of the best things about modern software development is that we don't have to build everything ourselves. Open-source libraries and third-party packages let us solve complex problems in minutes instead of days, allowing us to focus on what actually makes our applications unique.

That's why adding a dependency often feels like an obvious choice.

The problem is that every dependency comes with baggage.

You're not only importing code—you are also importing someone else's release cycle, security updates, breaking changes, licensing decisions, and maintenance priorities. Even the most popular packages can become abandoned or introduce changes that force you to adapt your own project.

That doesn't mean dependencies are bad. Many of them save hundreds of hours of work and have become industry standards for good reason. The key is being intentional instead of installing a package for every small problem.

Before adding a new dependency, I usually ask myself a few simple questions:

Does it solve a significant problem?
Is the project actively maintained?
Could I reasonably implement this myself?
If I needed to remove it later, how difficult would that be?

Those questions don't always lead to the same answer, but they help avoid unnecessary complexity.

While building Convertim, I've found that saying "no" to an extra dependency is sometimes the better engineering decision. A few more lines of code today can mean fewer updates, fewer compatibility issues, and less maintenance in the future.

Architecture isn't only about choosing the right technologies.

Sometimes it's also about choosing what not to add.

The Features We Chose Not To Build

Christian • ancer — Wed, 22 Jul 2026 09:00:00 +0000

When people talk about software development, the conversation usually revolves around what gets added. New features generate excitement, screenshots, release notes and marketing material. They give users something tangible to explore and give developers something new to build. It's easy to believe that the value of a product grows in direct proportion to the number of capabilities it offers.

In reality, some of the most important product decisions never appear in a changelog.

Every feature starts as a good idea. Someone encounters a problem, imagines a solution and suggests adding another option, another setting or another workflow. Looking at those ideas one by one, it's surprisingly difficult to reject them because each proposal often makes perfect sense on its own. The challenge only becomes visible when you look at the product as a whole instead of evaluating individual requests.

Every Feature Is a Long-Term Commitment

Adding functionality isn't just about writing code. Every new feature becomes part of the application for as long as the product exists. It needs documentation, testing, maintenance and compatibility with everything that comes afterwards. Future updates have to take it into account, bug fixes become more complicated and every new release has one more moving part that can potentially fail.

Those costs are rarely obvious when the feature is first implemented. At that moment, all you see is the problem it solves. The maintenance cost only becomes apparent months or even years later, when the product has evolved and dozens of independent decisions begin interacting with one another.

That's why product development isn't simply a process of adding value. It's also a process of deciding which responsibilities you're willing to carry in the future.

The Best Question Isn't "Can We Build It?"

As developers, we naturally enjoy solving technical problems. When someone suggests a useful feature, the first instinct is often to think about how it could be implemented. Modern frameworks, libraries and development tools make building software faster than ever, which means the technical challenge is often smaller than it used to be.

The more interesting question isn't whether something can be built. It's whether it deserves to become part of the product.

Some ideas solve edge cases that affect very few people. Others introduce configuration screens that make the interface harder to understand. Some require new dependencies, increase testing effort or create maintenance work that continues long after the original problem has been forgotten.

A feature can be technically successful while still making the product worse.

Building Convertim Meant Rejecting Good Ideas

While building Convertim, there were plenty of ideas that looked genuinely useful. Some would have added flexibility, others would have supported additional workflows, and a few would probably have looked impressive on a feature list.

We still decided not to build them.

Not because they were impossible, but because they moved the application away from its main purpose. Convertim was designed to be a simple, local-first image conversion tool. Every feature that doesn't reinforce that goal has to justify the complexity it introduces, and many perfectly reasonable ideas simply couldn't pass that test.

Saying "no" isn't about limiting the product. It's about protecting it from gradually becoming something it was never intended to be.

Simplicity Doesn't Happen By Accident

Software naturally becomes more complex over time. Every new option, every additional workflow and every extra dependency increases the number of decisions both developers and users have to make. Left unchecked, complexity accumulates almost automatically.

Simplicity works differently.

A simple product is usually the result of dozens of conscious decisions to leave things out. Those decisions often happen long before users ever download the application, and they're rarely visible from the outside. Users don't know which features were rejected during development, but they do notice when a tool feels focused, predictable and easy to understand.

That's why simplicity should never be confused with a lack of effort. In many cases, it's the result of much more discipline.

Think Beyond The Next Release

It's tempting to evaluate features based on how exciting they are today. They make a roadmap look more impressive and provide something new to announce. The problem is that software doesn't stop evolving after the next release. Every decision becomes part of the foundation that future versions have to build upon.

One mindset that has helped me is to imagine maintaining today's decisions a year from now. If a feature still feels worthwhile after considering future updates, bug fixes and ongoing maintenance, it's probably a good investment. If its long-term value is difficult to justify, adding it simply because it's possible is rarely the right answer.

Thinking that way doesn't slow development down. It keeps the product moving in the right direction.

Final Thoughts

A product isn't defined only by what it includes. It's also defined by everything its creators intentionally leave out.

Users rarely ask whether a feature was difficult to build, but they immediately notice when an application feels focused, coherent and easy to use. Those qualities don't appear by chance. They're usually the result of hundreds of small decisions, many of which involve saying "no" to ideas that seemed perfectly reasonable at the time.

Sometimes the best feature isn't the next one you add.

It's the one you decide not to build.

Why Software Friction Matters

Christian • ancer — Sat, 18 Jul 2026 16:00:00 +0000

When we talk about improving software, the first idea is usually to add something new: another feature, another option, another way to customize the experience.

But many times, the biggest improvements come from the opposite direction. Removing unnecessary steps, reducing decisions users should not have to make, and making common actions feel simpler.

That is where software friction appears.

Friction is everything that creates distance between the user and the result they want to achieve. It can be an extra step repeated hundreds of times, a confusing setting, a slow process, or a workflow that forces people to adapt to the tool instead of helping them complete their task.

Individually, these problems usually look small. One extra click does not seem important. Waiting a few more seconds feels acceptable. Manually repeating an action once is not a big issue.

But software is built around repetition, and small moments of friction become much more noticeable over time.

Reducing friction is not only a design problem. It is also an engineering decision.

A simple experience often depends on things users never directly see: how the application is structured, how workflows are designed, which defaults are selected, and which features are intentionally kept simple.

The goal is not always to add more possibilities. Sometimes the better decision is making the existing workflow clearer, faster, and easier to understand.

Good software does not just solve a problem. It removes everything unnecessary between the user and that solution.

What is a small improvement in a tool that completely changed your experience using it?

Why Convertim Uses One Binary For GUI And CLI

Christian • ancer — Wed, 15 Jul 2026 09:00:00 +0000

When building Convertim, one of the early technical decisions was how different workflows should be supported. Some users prefer opening an application, dragging a few files, choosing an output format and pressing a button. Others prefer running commands, automating repetitive tasks or integrating tools into existing workflows.

Both approaches solve the same problem, but they represent different ways of interacting with software. The challenge was deciding whether those workflows should become separate tools or different ways to use the same application.

The initial decision

A common solution would have been creating two independent tools: a desktop application focused on visual interaction and a command-line tool focused on automation. This approach works well in many projects because each tool can evolve independently and focus on a specific type of user.

While designing Convertim, we looked at it from a different perspective. Were we actually building two different products, or were we creating two different ways to access the same functionality?

That question influenced the internal architecture. Instead of treating the graphical interface and the command line as separate projects, we decided to keep them as different entry points connected to the same core.

Separating interface from logic

One of the most important ideas behind this decision was separating the user interface from the actual processing logic. The conversion engine, file handling, validation and configuration should not depend on whether someone interacts with the application visually or through a terminal.

The graphical interface and the command line are simply different layers built around the same foundation. They receive different types of input, but the core responsible for processing those actions remains shared.

This separation means improvements made internally benefit both workflows. Changes to conversion logic, optimizations or bug fixes do not need to be implemented multiple times because both experiences rely on the same underlying system.

Avoiding duplicated implementations

Duplicating functionality can sometimes feel like the fastest solution, especially during the early stages of a project. Creating a separate CLI implementation alongside the desktop application would probably have worked initially.

The problem usually appears later, when both versions need to evolve. A bug fixed in one implementation needs to be fixed again somewhere else. A new option has to be added twice. Small differences slowly appear between tools that are expected to behave consistently.

Keeping a shared foundation helps reduce those problems. Not because having less code automatically means having better software, but because reducing duplicated logic usually makes a project easier to maintain over time.

Supporting different workflows

A graphical interface works well when direct interaction is the goal. Opening an application, selecting files and visually adjusting options can be the fastest and most comfortable experience for many users.

But not every workflow works that way. Some tasks are repetitive by nature. Some users need to process many files frequently or include conversion steps inside scripts and automated processes.

In those situations, forcing every interaction through a graphical interface creates unnecessary friction. The goal of adding CLI support was not to replace the GUI, but to provide another way to interact with the same tool depending on the context.

Sometimes clicking a button is the best experience. Sometimes running a command is.

The technical trade-offs

Keeping GUI and CLI together also introduces some challenges. A shared foundation requires clearer boundaries between different parts of the application because multiple interfaces depend on the same internal behavior.

Features need to be designed considering more than one interaction model. A change is not only a visual decision anymore; it can affect both manual and automated workflows.

Like most engineering decisions, this approach is a trade-off. Separate applications provide more independence, while a shared core provides more consistency and reduces duplicated work.

There is no universal answer. The right decision depends on the goals and constraints of each project.

Building around workflows

For Convertim, keeping GUI and CLI inside the same application was not about adding another feature. It was about designing the application around the idea that different users can have different workflows without needing completely different tools.

The visible part of software is usually the interface, but many of the decisions that define the experience happen much deeper in the architecture.

Good architecture often stays invisible.

And that usually means it is doing its job.

Good Software Adapts To People

Christian • ancer — Sat, 11 Jul 2026 09:00:00 +0000

When we build software, it's easy to assume there is a correct way to use it. We design interfaces, create workflows and make decisions based on how we imagine people will interact with what we are building.

But once a tool reaches real users, things are usually much more diverse.

Different people have different habits, requirements and ways of solving problems. Someone may need a simple interface to complete a task once in a while, while someone else may need to automate that same process hundreds of times as part of a larger workflow.

Neither approach is better than the other. They are simply different ways of working.

This is why flexibility is an important part of product design. Giving users different ways to interact with a tool is not about adding complexity. When done correctly, it's about removing friction.

A graphical interface can make a task more accessible and easier to understand. A command-line interface can make the same task easier to automate and integrate into existing processes.

Both exist for the same reason: helping people solve a problem in the way that makes the most sense for them.

Good software should not force everyone into the same workflow. It should provide a clear solution while respecting that different users have different needs.

Sometimes the best design decisions are not the ones that change how people work, but the ones that allow them to keep working naturally.

Technology should adapt to people, not the other way around.

What about you? Has a tool ever changed the way you work for the better, or did it force you to adapt to it?

Designing Software For Different Workflows

Christian • ancer — Wed, 08 Jul 2026 09:00:00 +0000

When we build a tool, it is easy to assume there is a correct way to use it. We design an interface, define an ideal flow, and think about how someone should interact with our product.

But when software reaches real users, a much more interesting reality appears: everyone has their own way of working.

One person may need to convert a single image before sending it by email or uploading it to a website. Another may process hundreds of files as part of a repetitive workflow. Some people prefer a graphical interface because it feels fast and visual, while others work from a terminal because they need automation and integration with other processes.

None of these approaches are wrong. They simply solve different needs.

Finding the balance between simplicity and flexibility

One of the biggest challenges when designing software is finding the right balance between keeping the experience simple and providing enough flexibility to support different scenarios.

A simple tool should not become a limited tool. At the same time, a powerful tool should not force every user to deal with complexity they may never need.

This was one of the ideas we kept in mind while building Convertim. For many users, converting an image should be a straightforward process: open the application, select files, choose a format, and get the result.

No unnecessary configuration. No additional steps. No need to understand how the tool works internally.

But there are situations where that same approach is no longer enough. If someone needs to convert large amounts of images regularly or integrate that process into another system, manually repeating the same steps stops being efficient.

The need changes, and the tool should be able to adapt.

Graphical interfaces and command lines solve different problems

Graphical interfaces and command-line tools are often treated as opposite approaches, but they are actually designed for different contexts.

A graphical interface lowers the barrier to entry. It allows someone to use a tool without reading documentation, remembering commands, or understanding technical details.

A command-line interface, on the other hand, enables different possibilities: automation, scripts, repetitive processes, and integration into larger workflows.

The important question should not be which option is better.

The question should be what the person using the tool actually needs.

A designer preparing images for a project and a developer processing them automatically may be solving exactly the same problem, but from completely different contexts.

Automation is also part of the user experience

Automation is sometimes associated with complex tools designed only for technical users, but its goal is usually the opposite: reducing unnecessary work.

Automation means removing repetitive actions so people can spend less time on mechanical tasks.

A good tool should allow users to start with something simple and provide more possibilities only when they become necessary. Not everyone needs access to every option from the beginning, and adding flexibility does not mean increasing the complexity of the main experience.

It means allowing each person to find the workflow that best fits their needs.

More features do not always create a better product

When developing software, it is tempting to measure the evolution of a product by the number of features it includes.

More options. More settings. More possibilities.

But every new feature also introduces new decisions, more maintenance, and greater responsibility over the complete experience.

The most important question is not:

Can we add this?

It is:

What problem are we solving?

Flexibility should be the result of understanding different use cases, not simply accumulating features.

Software should adapt to people

Every user has different habits, preferences, and needs. Trying to force everyone into a single workflow can end up creating more problems than it solves.

Good software should not force people to completely change the way they work.

It should fit naturally into it.

Because in the end, the best tools are often the ones that stop getting in the way and simply help people do what they need to do.

This article is part of the journey of building products at ancer.

Convertim is our first public tool: a local-first image converter focused on simplicity, privacy and flexible workflows.

https://ancer.es/en/project/convertim

Shipping Is Just the Beginning

Christian • ancer — Sat, 04 Jul 2026 09:00:00 +0000

When you've spent months working on a project, it's easy to believe that launch day is the most important milestone. For a long time, everything revolves around that date: finishing tasks, fixing last-minute bugs, preparing the website, taking screenshots, and polishing the documentation. It all seems to lead to one goal: shipping.

Then the day finally arrives. You hit the publish button, the project is live, and there's a real sense of excitement and relief. But the next morning, you realize that almost nothing has actually ended.

That's when the most interesting part begins.

People start using your software in ways you never expected. Small details that went unnoticed during development suddenly become obvious. Feedback starts coming in, and some of the decisions that once felt final are worth revisiting.

Over time, you realize that great products don't evolve only through big new features. More often, they improve through small, thoughtful changes: fixing a bug, simplifying a workflow, or removing a tiny piece of friction from the user experience. Those improvements may seem minor, but they're often the ones users appreciate the most.

That's why every launch is really the beginning of a conversation with the people using your product. Listening, learning, and continuously improving are just as much a part of software development as writing code. Releasing an application is an important milestone, but maintaining it and helping it evolve is what truly turns it into a product.

The most interesting part starts after release.

GUI or CLI? Why We Built Both

Christian • ancer — Sat, 27 Jun 2026 09:00:00 +0000

Software developers love debating interfaces.

Some people will always prefer a graphical interface, while others feel most productive inside a terminal window. The interesting part is that both groups are usually trying to solve exactly the same problem—they just have different workflows.

While building Convertim, we quickly realized that choosing one approach over the other would unnecessarily limit the tool.

For many users, drag and drop is simply the fastest way to work. Open the application, select a folder, choose the output format and click a button. No commands to remember, no documentation to read, and no setup required.

But developers and power users often have completely different needs.

They want to integrate image conversion into scripts, CI pipelines, automation tasks or batch jobs that run without human interaction. For them, opening a graphical application would only slow things down.

Instead of deciding which audience was "right", we decided to support both.

The graphical interface focuses on simplicity and discoverability, making common tasks accessible with just a few clicks. The command-line interface, on the other hand, exposes the same processing engine in a way that can be scripted and automated.

Neither interface is better than the other.

They simply solve different problems.

Good software should adapt to the user's workflow instead of forcing the user to adapt to the software. Whether someone prefers clicking buttons or writing commands shouldn't change the capabilities they have available.

In the end, both interfaces share the same goal: making image conversion as simple as possible while staying fast, local and predictable.

Sometimes the best engineering decision isn't choosing between GUI and CLI.

It's refusing to make users choose.

What about you? When a tool offers both options, which one do you reach for first: the GUI or the terminal?