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.
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.
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 Sep: M0-01: workspace bootstrap
- 1 Sep: Add the master plan, frozen at v1.0
- 1 Sep: M0-03 + M0-04: core enums, schemas, and the time rules
- 1 Sep: M0-05: schema, migration 0001, and createEntity
- 2 Sep: M0-06 + M0-07: materializer and read queries
- 2 Sep: M0-08 + M0-09: seeds and the public API
- 2 Sep: M0-10..M0-14: the app, link previews, and the smoke script
- 2 Sep: M0-02: split the plan into living docs. M0 complete.
- 2 Sep: M1-02..M1-07, M1-10: search, ICS, QR, jobs, caching
- 2 Sep: Fix: an unanchored qr/ gitignore pattern excluded source code
- 2 Sep: M1-08, M1-09, M1-11: i18n, analytics vocabulary, Docker image
- 2 Sep: M2: submissions, stewardship, and the loop closing
- 2 Sep: M4: the community graph — organizers, groups, projects, theme lens
- 2 Sep: Trip the wire when the server's route tests have no database
- 2 Sep: Make the image deployable: a migrate entrypoint, and JSON 404s for /api
- 2 Sep: Delete railway.json; it was never being read
- 2 Sep: Ship the seed inside the image, so production has content
- 2 Sep: Format docs/DEPLOY.md
- 2 Sep: Correct the documented pre-deploy command, and record two Railway traps
- 2 Sep: Put the production URL in the README
- 2 Sep: Make the app buildable for a phone: EAS profiles and a native API origin
- 2 Sep: Link the EAS project and finish the iOS config for TestFlight
- 2 Sep: Serve the files that make shared links open the app
- 3 Sep: Audit this app against the web atlas
- 3 Sep: Audit this app against the live web platform, from its source
- 3 Sep: Mirror the atlas's places, read-only (ADR-028)
- 3 Sep: Run the atlas mirror on deploy as well as nightly
- 3 Sep: README: where places come from
- 10 Oct: Guest events: five tabs, agenda, and labelled fixtures
- 10 Oct: Show what an event submission publishes before it is sent
- 10 Oct: Restyle the shell toward the board
- 10 Oct: Keep Calenda's flyer extraction and store it for review
- 10 Oct: Keep flyer photos, help, things and notices in review
- 10 Oct: Wire EAS Update on the Expo app
- 10 Oct: Keep the town column inside the phone
- 10 Oct: Say Ahora on a venue programme that has already started
- 10 Oct: Grant management of one place, profile, or event
- 10 Oct: Close the public calendar until an Aldea is active
- 10 Oct: Add Ask Aldea behind a flag
- 10 Oct: Use Phosphor icons and place Preguntar beside Publicar
- 10 Oct: Set Plus Jakarta, Fraunces, and the courtyard mark
- 10 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.
Habits
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?
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.
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.
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.
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.
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.
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.