How I work

Ship today, not tomorrow. If something is bounded – a fix, a small feature, a doc cleanup, a test – it ships in the session I noticed it. Carry-forward queues are friction; finished work that compounds is what makes a one-person studio actually work. The only acceptable reasons to defer: missing data, an upstream dependency, or something genuinely too large for a single session.

Read first, then build. Most teams ship faster than they read what they shipped. I’ve run month-long stretches where every project waited for its data read at the next decision point before any new building got approved. “What does the data say?” before “what’s next?” That’s the real limit on a small studio – how much evidence you have when a decision comes due, not how fast you can build.

Cite primary sources. Flag uncertainty. Complicate your own claim. Three operating disciplines I picked up from years of internal memos and never let go. If I make a non-trivial factual claim, the citation is inline near the claim. If I’m not sure, I say “working theory” – never pretend certainty I don’t have. If I have a position, I’ll name the strongest argument against it before pushing forward. Arguing against my own answer is what keeps the reasoning honest.

Plain English, not jargon. Industry-standard acronyms stay. Internal shorthand translates. Decisions surface as “tomorrow’s two metric checks need a working DB connection” – not “B-004 blocks W-014.” If a phrase belongs on a LinkedIn slide, it’s already been cut.

Devil’s advocate is a feature, not optional. Every meaningful decision gets an argued-against pass. The point isn’t to look balanced – it’s to find the thing I’m systematically not seeing. Some of the best calls I’ve made this year are positions I held only because the first version of the counter-argument didn’t survive scrutiny.

Heartbeat over hope. If a process is long-running – a build, a deploy, a vendor outreach – I post a status update at 20-minute cadence. Silence is just unobserved failure. This applies to everything: build outputs, partner reach-outs, my own progress on a hard problem.

Default Alive. Every Skylark project is a small profitable product designed to pay for itself, not a bet that needs Series A to survive. If you’re considering a Build Together engagement: the deal math has to work without acceleration. I’m not optimizing for a unicorn outcome. I’m building a beautiful portfolio studio that funds the life I want.

Calm tech. Attention is the scarce resource – not engagement metrics, not session length. Calm tech doesn’t mean low-stakes. It means respecting attention enough that a user is grateful when the product shows up. Anything we ship together has to pass the “would a smart reader feel they have to read this, or fall behind?” test. If not, the form is wrong.

What I won’t do. Founder-distribution as a strategy (I am never the channel). Polish-time exceeding market-need (that’s hiding from feedback). Plans without dates (effort labels are not commitments). “Best-in-class” / “synergy” / “leverage” / “delve” / any phrase that belongs on a deck. Mistaking a calm work pace for thoughtful work – sometimes it’s just procrastination dressed in contemplative language. I try to catch that one in real time.

You send a reaction. You get back a verified change – usually the same day. A client emailed late one night about a bug – they believed their edit had been lost. By 9:15 the next morning the root cause was found in the data trail, the fix was deployed, and my reply led with the one thing they actually cared about: “your edit did save.” On another engagement, a contract redline arrived one evening; the next day’s response opened with everything I was accepting – agreement first, asks second. An ask that landed at 11:35 AM was live by about 1 PM. None of this is heroics. It’s what one decision-maker plus a fleet of agents is actually for.

Nothing you say evaporates. Every round of feedback – a long written review, a call, a one-line reaction – gets broken into numbered points, and every point gets a written disposition: a faithful paraphrase of what you said, a ruling (accepted, deferred, or noted), the reason, and a pointer to where it landed. When I disagree, I argue it in writing instead of quietly dropping it. On one engagement that ledger has run for months – and the client pointed their own AI at the same repo and sent structured amendments back. Both sides’ machines reading the same repo, humans arbitrating. It worked.

I tell you when your asks are cheap. A client sent a batch of additions before signing. I marked roughly 80% of them as confirmations or cheap adds – absorbed into the work, no charge – and named exactly one item as real scope, with a price. The split was shown to them, not managed quietly on my side. Refusing to monetize the small stuff is what let the one real ask close without a fight.

I’ll push back on you, too. When a client approved a batch of items wholesale, I held one back because its underlying data had been flagged inaccurate. When a piece of requested copy called for a first-person anecdote that never happened, I cut the invention, kept what was true, and said what changed. Nothing a client reads from me is hoped-correct. It’s checked.

Direction changes get absorbed, not renegotiated. Mid-engagement, a client revealed they’d already built the thing I was building. My role inverted inside that same call – builder to reviewer – and useful work in the new role landed the next day. No change order. Scope lives in a running ledger that gets read at the start of every session and reconciled at the end, not in a fixed deliverable list – so the engagement turns when your situation turns.

The bill tracks engaged attention, not machine time. Adding agent capacity never raises the invoice. Ramp-up and admin don’t get billed. A quiet week legitimately bills near zero – and when an engagement idles because the person I need is consumed elsewhere, I say it’s idling instead of manufacturing activity to fill an invoice.

Pre-registered gates. Before I test whether an improvement of mine actually worked, the pass/fail rule and the evaluation data get committed – frozen before any results exist, the way a clinical trial registers its endpoints before looking at outcomes. Work that fails its gate is discarded, not shipped. This year an upgrade I built failed its pre-registered comparison and got thrown away. The industry default is to ship whatever got built. I’d rather eat the sunk cost.

Prove the instrument can fail. Every automated checker has to demonstrate a true negative at write time – show me it catches a planted failure – before I believe anything it says, because a check that has never failed looks exactly like a check that never ran. And a clean bill of health is the most suspicious output a checker can produce, so clean results get independently re-derived before they reach a client. I learned both rules the expensive way: I once sent a clean audit result that was wrong, retracted it in writing the same day, and had the new rules running as standing machinery within a day of the incident. A law without an instrument is a wish.

Adversarial review as a release gate. Before work leaves, a second model family – one with no stake in the reasoning that produced the work – is prompted to refute the claim set. Whatever survives gets re-verified against live code. The point is to deliberately spend compute making it harder for a wrong claim to survive. This gate once caught a second bypass in an already-reviewed fix before the client ever saw it. The attacker’s findings are treated as hypotheses, not verdicts – it gets things wrong too. Its job is to make me look again.

The notes are not a source. Anything that leaves here carrying a factual claim gets re-derived from primary sources at send time – the running code, the original document, the live data – explicitly not from the engagement’s own notes. The failure mode is real: a compressed note of mine once matured, through rounds of summarization, into a confident claim that someone had checked a thing. Nobody had. A scheduled pre-send verification pass caught it, cut it, and re-derived the findings from live code before the client saw a word.

Render as recipient. Before anything ships, I open it in the exact medium the recipient will see – the inbox, the deployed page, the phone – never just the editor it was written in. Small rule, real catches: a wrong character in a button label that every local check had waved through.

I’m one person with an unusually good harness, not a delivery shop. There’s no bench of named humans behind me, and every client-facing judgment funnels through one head. If procurement needs a team org chart, this won’t fit.

The loop runs on your reactions. I work async-first – artifacts land in your inbox, and one line from you can re-sort my whole week – but that cuts both ways: a quiet client starves the engagement. This works when someone on your side reads what lands and reacts to it. Best case, that someone can take a pull request, argue a finding, and merge.

Gate discipline reads as slow if you count switched-on features. Some finished work sits dark behind a comparison it hasn’t passed. If velocity to you means feature count, I will look slower than a shop that ships whatever got built – and I’m not going to change that.

Bad fits, named plainly. Standing-meeting cultures – my calls are decision events, scheduled when a decision needs one, not a daily ritual. Fixed-scope builds thrown over a wall – I won’t take a spec and disappear for six weeks. Staff augmentation – I’m not a body to slot into your sprint. If that’s the shape you need, there are good shops for it; I’m not one.