How I work

There is no methodology here. There are a few habits, and the repositories show them more reliably than any description would. Planning, deciding, building, checking and shipping do not happen in phases; they happen in the same afternoon.

Working principle

Don’t make the architecture impressive.
Start with the user problem. Choose the smallest useful version. Build the whole loop. Put it in front of people. Then earn the complexity.

What overlap looks like

Every commit to one project, sorted by what it did. Hover a column for its message, or open the full list below the chart.

Hacer Aldea, all 50 commits by what they didVerified, from the commit history
A dot chart. Each column is one commit, left to right in time. Rows are plan and scope, decide, build, verify, ship and write it down. Five of the six rows have dots on the first day, and the first public deploy lands on day two.Plan and scopeDecideBuildVerifyShipWrite it down1 Sep2 Sep3 Sep10 Oct12 Octfive weeks1 Sep: M0-01: workspace bootstrap1 Sep: Add the master plan, frozen at v1.01 Sep: M0-03 + M0-04: core enums, schemas, and the time rules1 Sep: M0-05: schema, migration 0001, and createEntity2 Sep: M0-06 + M0-07: materializer and read queries2 Sep: M0-08 + M0-09: seeds and the public API2 Sep: M0-10..M0-14: the app, link previews, and the smoke script2 Sep: M0-02: split the plan into living docs. M0 complete.2 Sep: M1-02..M1-07, M1-10: search, ICS, QR, jobs, caching2 Sep: Fix: an unanchored qr/ gitignore pattern excluded source code2 Sep: M1-08, M1-09, M1-11: i18n, analytics vocabulary, Docker image2 Sep: M2: submissions, stewardship, and the loop closing2 Sep: M4: the community graph — organizers, groups, projects, theme lens2 Sep: Trip the wire when the server's route tests have no database2 Sep: Make the image deployable: a migrate entrypoint, and JSON 404s for /api2 Sep: Delete railway.json; it was never being read2 Sep: Ship the seed inside the image, so production has content2 Sep: Format docs/DEPLOY.md2 Sep: Correct the documented pre-deploy command, and record two Railway traps2 Sep: Put the production URL in the README2 Sep: Make the app buildable for a phone: EAS profiles and a native API origin2 Sep: Link the EAS project and finish the iOS config for TestFlight2 Sep: Serve the files that make shared links open the app3 Sep: Audit this app against the web atlas3 Sep: Audit this app against the live web platform, from its source3 Sep: Mirror the atlas's places, read-only (ADR-028)3 Sep: Run the atlas mirror on deploy as well as nightly3 Sep: README: where places come from10 Oct: Guest events: five tabs, agenda, and labelled fixtures10 Oct: Show what an event submission publishes before it is sent10 Oct: Restyle the shell toward the board10 Oct: Keep Calenda's flyer extraction and store it for review10 Oct: Keep flyer photos, help, things and notices in review10 Oct: Wire EAS Update on the Expo app10 Oct: Keep the town column inside the phone10 Oct: Say Ahora on a venue programme that has already started10 Oct: Grant management of one place, profile, or event10 Oct: Close the public calendar until an Aldea is active10 Oct: Add Ask Aldea behind a flag10 Oct: Use Phosphor icons and place Preguntar beside Publicar10 Oct: Set Plus Jakarta, Fraunces, and the courtyard mark10 Oct: Format the help tests and the flyer ingest route.10 Oct: Record the build audit and the photo-library sentence.10 Oct: Note that the simulator home icon is the courtyard mark.10 Oct: Give closed towns a desktop cover.10 Oct: Read flyers in production and turn Preguntar on.12 Oct: Add the Fastlane lane that ships a TestFlight build.12 Oct: Serve a privacy policy and support page in the app and on the web.12 Oct: Add Red local, a private prospect list for stewards.12 Oct: Keep Fastlane output and generated files out of pnpm check.

A vertical line joins the activities a single commit touched. The blue dots mark the commit that put the public deploy's URL in the README, on day two.

All 50 commit messages
  1. 1 Sep: M0-01: workspace bootstrap (build)
  2. 1 Sep: Add the master plan, frozen at v1.0 (plan, document)
  3. 1 Sep: M0-03 + M0-04: core enums, schemas, and the time rules (build, decide)
  4. 1 Sep: M0-05: schema, migration 0001, and createEntity (build, decide, verify)
  5. 2 Sep: M0-06 + M0-07: materializer and read queries (build)
  6. 2 Sep: M0-08 + M0-09: seeds and the public API (build)
  7. 2 Sep: M0-10..M0-14: the app, link previews, and the smoke script (build, verify)
  8. 2 Sep: M0-02: split the plan into living docs. M0 complete. (plan, document)
  9. 2 Sep: M1-02..M1-07, M1-10: search, ICS, QR, jobs, caching (build)
  10. 2 Sep: Fix: an unanchored qr/ gitignore pattern excluded source code (verify)
  11. 2 Sep: M1-08, M1-09, M1-11: i18n, analytics vocabulary, Docker image (build, ship)
  12. 2 Sep: M2: submissions, stewardship, and the loop closing (build)
  13. 2 Sep: M4: the community graph — organizers, groups, projects, theme lens (build)
  14. 2 Sep: Trip the wire when the server's route tests have no database (verify)
  15. 2 Sep: Make the image deployable: a migrate entrypoint, and JSON 404s for /api (ship)
  16. 2 Sep: Delete railway.json; it was never being read (ship)
  17. 2 Sep: Ship the seed inside the image, so production has content (ship)
  18. 2 Sep: Format docs/DEPLOY.md (document)
  19. 2 Sep: Correct the documented pre-deploy command, and record two Railway traps (document, ship)
  20. 2 Sep: Put the production URL in the README (document, ship)
  21. 2 Sep: Make the app buildable for a phone: EAS profiles and a native API origin (ship)
  22. 2 Sep: Link the EAS project and finish the iOS config for TestFlight (ship)
  23. 2 Sep: Serve the files that make shared links open the app (build)
  24. 3 Sep: Audit this app against the web atlas (plan, decide)
  25. 3 Sep: Audit this app against the live web platform, from its source (plan)
  26. 3 Sep: Mirror the atlas's places, read-only (ADR-028) (decide, build)
  27. 3 Sep: Run the atlas mirror on deploy as well as nightly (ship)
  28. 3 Sep: README: where places come from (document)
  29. 10 Oct: Guest events: five tabs, agenda, and labelled fixtures (build)
  30. 10 Oct: Show what an event submission publishes before it is sent (build)
  31. 10 Oct: Restyle the shell toward the board (build)
  32. 10 Oct: Keep Calenda's flyer extraction and store it for review (decide, build)
  33. 10 Oct: Keep flyer photos, help, things and notices in review (build)
  34. 10 Oct: Wire EAS Update on the Expo app (ship)
  35. 10 Oct: Keep the town column inside the phone (verify)
  36. 10 Oct: Say Ahora on a venue programme that has already started (build)
  37. 10 Oct: Grant management of one place, profile, or event (build)
  38. 10 Oct: Close the public calendar until an Aldea is active (plan, build)
  39. 10 Oct: Add Ask Aldea behind a flag (build)
  40. 10 Oct: Use Phosphor icons and place Preguntar beside Publicar (build)
  41. 10 Oct: Set Plus Jakarta, Fraunces, and the courtyard mark (build)
  42. 10 Oct: Format the help tests and the flyer ingest route. (verify)
  43. 10 Oct: Record the build audit and the photo-library sentence. (document)
  44. 10 Oct: Note that the simulator home icon is the courtyard mark. (document)
  45. 10 Oct: Give closed towns a desktop cover. (build)
  46. 10 Oct: Read flyers in production and turn Preguntar on. (ship)
  47. 12 Oct: Add the Fastlane lane that ships a TestFlight build. (ship)
  48. 12 Oct: Serve a privacy policy and support page in the app and on the web. (build, ship)
  49. 12 Oct: Add Red local, a private prospect list for stewards. (build)
  50. 12 Oct: Keep Fastlane output and generated files out of pnpm check. (verify)

Habits

  1. Find the loop before the feature

    I start with who does what, and what comes back to them. Hacer Aldea's plan asks of every ticket which loop it strengthens, what triggers it and what happens when it fails. Orbis started from one question: which agent needs me right now?

  2. Scope by what not to build

    Saying what a product is not does more work than a feature list. Hacer Aldea is explicitly not a social network, a marketplace or a chatbot, and a town's public calendar stays closed until that community is active.

  3. Decide in writing, with the option that lost

    Architecture decisions go in a log with the problem, the choice, its cost and the alternative that was rejected. It stops the next engineer, or the next agent, from undoing a decision by accident. The ones that matter are on the Hacer Aldea case study.

  4. Ship a thin version on real infrastructure

    A public deploy with link previews and a smoke test existed on Hacer Aldea's second day. Real infrastructure surfaced real problems early: a config file the host was never reading, a pre-deploy command that was wrong in the docs.

  5. Verify the verifier

    Tests that skip quietly are worse than no tests. Database tests run against a real Postgres, CI fails if they did not run, and a migration-drift check that once passed when it should have failed is now tested in both directions.

  6. Say what is not done

    Every case study on this site has a “Not done” list, taken from the project's own notes. A status that means what it says is worth more than a demo that hides the gaps.

  7. Leave it so someone else can carry on

    Decisions, deploy steps and the traps found along the way get written down where the code lives, so the next person, or the next agent, does not have to rediscover them.

Working with AI agents

Claude Code agents write a lot of my code, often several sessions in parallel. That changes what my job is, not whether I own the result.

  • I write the plan, and the rules the agents work under.
  • Boundaries are enforced by tools, like lint rules on imports, not by trusting the agent.
  • A single check command is the definition of done: types, lint, format, migrations and tests.
  • I review what merges, and I am the one who answers for it.
  • Anything that can act on the world sits behind server-side gates. Orbis is the story of learning that one properly.

Inside a team

In someone else's codebase I work the way the team works. At Hostology that meant building features from the CEO's specs and the design team's Figma, in the existing C#/.NET domain layer and GraphQL API, behind feature flags, with API tests that run as each user role. At Movebubble it meant taking the Negotiator app from prototype to a fully functioning cross-platform app inside a product team, work their technical lead later described as a vital part of the business.

I am comfortable being the only engineer, and equally comfortable being one of several. What I need is access to the people who know the problem.