The publishing studio
The custom CMS behind Field Notes: a markdown editor with live preview, scheduled publishing, and a leads inbox. Built for the practice itself in Next.js and PostgreSQL.
The process
Vol. VI · MMXXVI
§ 00 · the method
I map how your business runs before we build anything.
Most help starts with a tool or a template. I start with how clients actually get found, sold, onboarded, delivered to, and offboarded, including the manual stitching you do without realizing it. Only then do we design and build.
§ 01 · the sequence
Four phases, in order.
Each one earns the next. Nothing gets built before it is understood.
- 01
Map
Set where you are headed, then trace how the business actually operates against that. This is the diagnostic: the real sequence of the work, not the org chart, where every gap first shows.
this is the diagnostic
- 02
Design
Decide what the operation should look like, which tools earn their place, what gets retired, and where a custom build does what no off-the-shelf tool can.
- 03
Build
The custom pieces in Next.js and PostgreSQL, the stack connected, the manual work retired. This is the half most partnerships hand off. We don't.
- 04
Maintain
Systems drift back into workarounds when no one tends them. On a retainer, we keep yours current as the business grows.
this is the retainer
Map is the diagnostic; Maintain is the retainer. Pricing is on the Services page.
§ 02 · the audit lens
The lens the diagnostic looks through.
Four areas, examined together, because the real gaps almost always cross more than one.
Systems
How the work gets done, and where it still routes through you.
Finance
How money moves, operationally, and whether you can see your numbers clearly enough to decide. Not bookkeeping.
Positioning
Whether what you say matches what you sell, and the structure underneath.
Client Experience
Onboarding, delivery, offboarding, and the handoffs that depend on you being in the room.
One partnership for both
Operations help usually stops where the build begins. Ours doesn’t.
The usual split
An OBM maps the problem, then hands the build to a developer who was never in the room. What comes back is technically correct and slightly wrong, or the cost of a second hire kills the idea and you settle for another workaround. Either way the thinking gets lost, and you hold both halves together.
How I work
I map the operations and design the system; my team and I build the custom tools when software won’t do the job. The diagnosis informs the design; the design informs the build. Nothing gets handed off. This is real work in Next.js, PostgreSQL, and AI-augmented development, not a theoretical capability.
Most operational partnerships top out at “you’ll need a developer for that.” We don’t have that ceiling.
§ 03 · selected work
Proof that we build, not just advise.
A few builds, shown as evidence.
The business register
A working prototype for the Bermuda Economic Development Corporation: a business register with staff review workflows, a document vault, and a work hub that routes each day’s tasks.
The full record
Bermuda Trivia · Store Tunes · Odetunde Law
The client site builds, photographed in the studio, live on the portfolio alongside these two.
§ 04 · working together
The shape of an engagement, so there are no surprises.
A partnership moves through four stages, on a predictable rhythm.
01
The diagnostic
I map the business and hand you the audit, roadmap, and a proposal.
02
The proposal
The one project to start with, or the retainer, scoped against what the audit found.
03
The project or retainer
The work itself, on a defined scope, or ongoing leadership on a retainer.
04
Studio hours
Your standing access window during a retainer.
Cadence
Business hours, async replies inside a day or two, bounded on purpose. A partnership that burns out the people in it serves no one.
§ 05 · why I map first
Why I map first, every time.
The method comes from watching builds fail because they started in the wrong place: a portal that did sixty percent of the job, a developer solving a problem nobody had diagnosed. Good technical work, aimed slightly wrong, because the operational reality under it was never mapped. I learned both halves so the diagnosis and the build stop getting lost between two sets of hands.
The fuller story →§ 06 · begin
Start with a diagnostic.
The low-commitment way to see how I think before any larger decision. You leave with an audit and roadmap that are useful on their own.
Let me know your thoughts and we can go from there.