How a Solo Indie Dev Runs a Full Stack Through Claude Cowork (iOS + Android + Backend)

Nagi Punyamurthula — Fri, 21 Aug 2026 20:28:51 +0000

How N0AGI LLC runs an entire product-engineering loop — two mobile platforms at feature parity, plus the production web app and API backend that power them — as a part-time solo operator, using Claude Cowork with a custom governance skill system.

Why this writeup exists

Most public Claude Cowork demos show the same two things: sorting a messy Downloads folder, or building a go-to-market pipeline. Impressive, but they don't answer the question I actually had as an indie developer: can this thing carry real, shipped product engineering — the kind you put your name and an LLC behind?

This is my answer. I'm a part-time, self-funded solo developer operating as N0AGI LLC. I ship native mobile apps to both the App Store and Google Play kept at feature parity, and I run the production web app and API backend those apps depend on — the whole stack, frontend to backend to two mobile clients — on a limited weekly time budget. I run that entire loop through Claude Cowork, steered by a small system of custom skills I wrote to keep an autonomous agent inside guardrails I trust.

The point I want to make to other indies — and, honestly, to Anthropic — is that Cowork isn't just a productivity toy for non-coders. In the hands of a solo developer it's a force multiplier that makes an entire product stack — two mobile platforms at parity plus the backend that serves them — survivable for one person.

73 by N0AGI, live on both stores — iOS above, Android below.

The apps

I'll ground everything in three real, shipped products so nothing here is hypothetical — and, importantly, they aren't three isolated apps. They're a stack.

73 by N0AGI — an FCC callsign lookup tool for amateur radio operators. (My own callsign is N0AGI; "73" is ham shorthand for "best regards.") It's a focused utility: fast lookups against FCC license data, built for operators who want the answer in one tap.

call.n0agi.com — and this is the piece that reframes the whole story. It's a production-grade web app that serves both a public frontend and the API backend stack that the 73 mobile app depends on. In other words, 73 isn't a standalone client hitting some third-party service — it's a client of a backend I designed, built, and operate myself, through Cowork. This is the part I most want to highlight: Cowork isn't just helping me port UI between two phones. It's carrying a real full-stack system — server, API, and two native clients — that has to stay coherent end to end.

ChipVault — an NFC reader/writer built around MIFARE DESFire EV2/EV3 secure elements with AES-128, on a strict no-cloud privacy model. Nothing leaves the device. That privacy-first architecture is the through-line of everything I build, and — as I'll explain — it's also why the way I use Cowork matters as much as the fact that I use it.

Where things stand — August 2026

73 by N0AGI — iOS v1.2.3, Android v0.1.5, running at feature parity: same FCC ULS data layer, same search, filters, favorites, history, stats and themes, same one-time $2.99 on both stores. 73 for Android first shipped to Google Play on 2026-07-02, written in Kotlin + Jetpack Compose + Material 3.
App Store · Google Play · products.n0agi.com

And here's the part that makes 73 more than a two-platform story: call.n0agi.com. I self-host it, and I built it the same way I build everything else — through Cowork. It runs on Go, chi and SQLite, and it serves the public web frontend and the API stack that 73 calls, pulling FCC ULS and RadioID.net data on nightly and weekly refresh cycles. 73 isn't a mobile skin over somebody else's service. The backend it talks to is mine, end to end.

ChipVault — iOS v2.4.0, Android v1.4.0, both released on 2026-08-17 carrying the same feature set on both platforms. Personalize a card on one, read it on the other.
App Store · Google Play · products.n0agi.com/chipvault
No cloud anywhere in the design: MIFARE DESFire EV2/EV3, AES-128, and nothing that leaves the card and the phone.

The actual problem: parity is a tax that scales with platforms, not with users

Here's the thing nobody tells you about going cross-platform as a solo dev. The cost isn't writing the second app. It's keeping the two apps honest with each other forever after.

Every feature is now two implementations. Every bug fix has to be checked on both sides. Every store submission has two sets of metadata, two review processes, two sets of screenshots at different aspect ratios. A change that's a 20-minute job on one platform quietly becomes a half-day when you count the parity work, the cross-checking, and the context-switching between two toolchains and two languages.

For a full-time team, you throw people at it. For a part-time solo operator, that tax is the thing that kills cross-platform ambitions before they ship. My scarcest resource isn't skill or ideas — it's hours, and parity work is where hours go to die.

That's the specific problem I pointed Cowork at. Not "write my app for me." Keep my two apps in sync without me having to hold both entire codebases in my head at once.

How I run it: Cowork as the parity engine

The mental model that made this click: I do the thinking on one platform; Cowork carries the decision to the other and tells me where they've drifted.

A typical cycle looks like this:

I design and implement a feature on the lead platform (usually iOS, in Xcode, since that's my home turf). This is the part I want human judgment on — the UX decisions, the tricky protocol work, the security-sensitive bits in ChipVault.
I hand Cowork the diff and the intent. Not "port this," but "here's what changed and why — bring the Android side to matching behavior, and flag anything that can't map cleanly." The "why" matters: it lets the agent make the right call when the platforms genuinely differ instead of blindly translating.
Cowork works across both project directories. Because it operates on my actual files, it can read both codebases, produce the parallel implementation, and — critically — surface the places where iOS and Android shouldn't be identical (platform conventions, permission models, the NFC and secure-element APIs that differ between CoreNFC and Android's NFC stack).
I review and steer. I'm never handing over the keys. I'm reviewing a proposed parallel change against a decision I already made and understand.
Parity audit. This is the highest-leverage part. I can ask Cowork to compare the two codebases against a feature checklist and tell me where they've diverged — the thing that, done by hand, is the single most tedious and error-prone job in solo cross-platform work.

The result isn't that Cowork writes my apps. It's that the parity tax — the thing that made two platforms feel impossible for one part-time person — got small enough to pay.

Beyond the phones: running a full-stack backend the same way

The parity loop above is the mobile half. The part that surprised even me is how well the same working model extends to the backend.

call.n0agi.com isn't a toy. It's a production web app that serves a public frontend and, behind it, the API stack that the 73 mobile app calls. That means a change is rarely confined to one surface — a new capability in 73 might need an API endpoint on the backend, a change to the web frontend, and matching client code on both iOS and Android. Four moving parts that all have to agree on the same contract.

Holding that whole chain in your head as one person is exactly the kind of thing that used to make me scope features down or not ship them at all. Now the loop looks like: I decide the contract — what the endpoint does, what it returns, how the clients consume it — and Cowork carries that single decision coherently across the backend, the web frontend, and the two mobile clients, flagging where each layer needs something different. The agent isn't just translating UI between two phones; it's keeping a system internally consistent, from server to API to client.

For a solo operator, that's the difference between "I have a mobile app" and "I run a full-stack product." The second one used to require a team.

           FCC ULS  ·  RadioID.net
                     │  nightly + weekly data pull
                     ▼
           call.n0agi.com — self-hosted
              ┌──────────┴──────────┐
         web frontend              API
              │                     │
              ▼                     ▼
          web users        73 iOS  ·  73 Android

One data layer behind one host: the browser gets the frontend, the phones get the API. Every box is mine, and every box gets built the same way.

Here's a piece of it — the part that decides whether a licensee's home address ever leaves the server:

// applyAddressPrivacy mutates cs in place to redact street address + ZIP
// when the admin has set show_street_address=false. No-op if cs is nil.
func (h *Handler) applyAddressPrivacy(cs *models.CallSign) {
    if cs == nil { return }
    show, _, _ := h.store.GetSetting("show_street_address")
    if show != "false" { return }
    placeholder, ok, _ := h.store.GetSetting("redact_placeholder")
    if !ok || placeholder == "" { placeholder = "[PRIVATE]" }
    cs.AddressLine1 = placeholder
    cs.ZipCode      = placeholder
}

The FCC publishes every licensee's street address. On my instance that setting is off, so the redaction happens right here — server-side, before the JSON is serialised — rather than in the app, where a client could simply decide not to honour it.

The part I think is actually novel: governance skills

Handing an autonomous agent access to real, shipped product code should make any serious developer nervous. It made me nervous. An agent confidently doing the wrong thing across a live codebase is a real risk, not a hypothetical one.

So I didn't just use Cowork out of the box. I built a small system of custom skills to put structure around every working session — a lightweight constitution for how the agent is allowed to operate on my projects.

Two of them anchor every session:

/checkin — a ramp-up ritual I run at the start of a session. It re-establishes the ground rules, the engagement model, and the project context before any work happens. Think of it as the agent reading its own operating manual before touching anything.
/checkout — a session-end ritual. It drafts the record of what happened and updates my task and build logs.

The decision that matters is what the agent may change on its own. Routine session records — what happened, what shipped, what's still open — it writes itself, because those are reversible and I can see them. The rules it operates under, and anything that would carry a decision into another project, it can only propose. I approve, or it doesn't land.

That's the asymmetry the whole thing rests on: the agent can revise the record of what happened; it cannot revise the rules it works under. Everything I'm comfortable delegating sits on top of that one line — and it's what lets me hand off real work without lying awake about it.

/checkin at the start of a session — documents loaded with their hashes, every discipline in force, project state recovered before any work happens.

/checkout at the end — the session record auto-writes; anything canonical stops and waits. "Say cancel or edit to intervene."

This is the part I'd most want an Anthropic DevRel or partner-team person to see. It's evidence that the skills/plugin system enables solo developers to build the trust scaffolding that makes agentic development safe enough to bet a business on.

Why the privacy-first angle matters here

Everything I ship runs on a no-cloud model — ChipVault most strictly. That creates an obvious tension with using a cloud AI agent, and I want to be straight about how I resolve it, because other privacy-minded builders will have the same question.

The distinction I hold: Cowork is part of my development environment, not part of my product's runtime. My users' data never touches it. What Cowork sees is my own source code and my own project files, during my own build process — the same category of thing my IDE and my version control see. ChipVault makes no network calls at all; 73 talks only to my own server. The privacy promise I make to my users is about the app's runtime behavior, and that promise is intact.

For anyone building on a trust-differentiated, no-cloud model: this line — dev-time tooling vs. product runtime — is the one that lets you use a cloud agent without undercutting your own positioning. Worth deciding deliberately rather than by accident.

I checked my own settings rather than assume. I'm on a Max plan with "Help improve our AI models" turned off, so my chats and coding sessions aren't used to train models, and they're kept for 30 days instead of five years. On consumer plans that's opt-in rather than on by default — but it is a setting, so it's worth opening yours and looking rather than taking anyone's word for it.

What actually changed, honestly

Let me keep this grounded and avoid the breathless-demo tone.

What got dramatically better:

Parity work stopped being the bottleneck. The cross-platform tax dropped from "the reason not to do it" to "a manageable line item."
The tedious, error-prone parity auditing — the worst job in solo cross-platform dev — became something I could ask for on demand instead of dreading.
Context-switching cost between two toolchains dropped, because I'm holding one platform in my head and letting the agent carry the bridge.

What still needs me:

The hard thinking — architecture, security-sensitive code, UX judgment — is still mine, and should be. Cowork is a parity engine and a force multiplier, not a replacement for the decisions that make the product good.
Review discipline is non-negotiable. The governance skills exist precisely because "trust but verify" has to be structural, not aspirational.

One concrete number, from the most recent thing I shipped. ChipVault's Public Record feature — writing an NDEF record onto the card so any stock phone can read it — went from locked design to live on both stores in five days: design settled on 12 August, the iOS build hardware-verified on the 14th, the Android port hardware-verified on the 16th, both versions submitted on the 17th. That's a new wire format, a provisioning path, key derivation and an eleven-field editor, done twice.

The five days isn't really the number that matters to me. It's that the Android port finished the same day the iOS side did. The release before it went the same way — iOS diagnostics build one day, the Android parity port the next.

The real change: from doing everything to steering everything

I want to close with the part that actually matters to me, because it's bigger than any workflow tip.

Before Claude Cowork, being an indie developer meant being all of it. I designed. I architected. I wrote every line on every platform. I tested. I did the marketing. Every one of those hats sat on one head, and the number of hats is exactly why so many indie ideas never ship — not because they're bad ideas, but because one person cannot sustainably wear all of them at once, part-time, forever.

What changed isn't that I got faster at wearing the hats. It's that I took one off.

Leaning on Cowork moved me out of the pure-developer seat. My software engineering — the implementation across iOS, Android, the web frontend, and the backend — I now delegate to Cowork, with my governance skills as the guardrails and my review as the final gate. That freed me to do the thing I'm actually best positioned to do as the person who owns the vision: steer product strategy. Decide what to build and why. Own the architecture and the contracts. Shape the roadmap. Make the calls that need human judgment and taste.

In practical terms, my role changed from developer to something closer to a product officer — the person setting direction — with Cowork as my software engineering function. Not an assistant that autocompletes a line here and there. The engineer that takes a decision I've made and carries it, coherently, across the whole stack.

I want to be precise about that claim, because "I delegate 100% of my engineering to an AI" is the kind of line that makes a serious developer wince — and they'd be right to. The honest version is sharper: I delegate the implementation fully, but never the judgment. Every session runs inside the checkin/checkout guardrails, and every change passes my review before it's real. That's the whole point. Full delegation without structural review is recklessness; structural review without delegation is just doing all the work yourself. The thing that actually changed my life is the combination — I hand off the entire engineering execution and I keep a disciplined gate on it. Steering with real guardrails, not hands-off. That pairing is the part I'd stake my name on, precisely because it's the part that makes trusting an agent with a live, shipped codebase defensible.

That's the transformation I'd want other indies to hear, because it reframes what this technology is for. It didn't just make me a faster coder. It changed what my job is. For the first time, being a one-person shop doesn't mean being stretched across every discipline until the thin spots tear — it means owning the decisions that only I can make, and having a capable engineering function to execute them. That's not a small productivity gain. For a solo operator, it's a different life.

For other indie developers

If you're a solo or very small shop weighing cross-platform, the takeaway I'd offer:

The reason "just build both" feels impossible isn't the second codebase — it's the forever cost of keeping them honest. That's the specific cost an agent that works on your real files can absorb. Start with one folder and one narrow task (I'd suggest a parity audit, not a full port — it's the fastest "oh, this is real" moment). Build yourself a checkin/checkout discipline before you scale up what you delegate. And decide your dev-tooling-vs-runtime privacy line on purpose.

You don't need a team to ship two-platform parity anymore. You need a lead platform you understand deeply, a disciplined loop, and an agent you've put real guardrails around.

For Anthropic

If anyone from the Claude Code / Cowork team reads this: the indie, self-funded, part-time developer is a user profile your public examples don't really cover, and I think it's a more interesting one than it looks. We're the case where Cowork isn't a convenience — it's the thing that makes an otherwise-impossible scope (a full stack — backend, web, and two mobile clients — run by one person on limited hours) actually shippable. We're building non-trivial governance systems on top of your skills primitive to make agentic development trustworthy enough to run a business on. And for at least one of us, Cowork didn't just speed up the work — it changed the job, from wearing every hat to steering product strategy with Cowork as the engineering function.

I'd be glad to show the full workflow — the cross-platform parity loop, the full-stack backend work behind call.n0agi.com, and the checkin/checkout governance system, mapped to real shipped products — in more depth.

N0AGI LLC — n0agi.com · N0AGI@N0AGI.com

73 by N0AGI — App Store · Google Play
ChipVault — App Store · Google Play
call.n0agi.com — the web app and API behind 73

Nagi — N0AGI LLC. Licensed amateur radio operator, indie iOS/Android developer, privacy-first by default.

DEV Community: Nagi Punyamurthula