At Heldcraft, "built with care" isn't a marketing line. It's an operating principle — and nowhere is that more visible than in how we think about the people who use our software.

Care means not taking what isn't yours

Most analytics and monitoring setups are built around a simple assumption: more data is better. Collect everything, store it indefinitely, figure out what's useful later. It's efficient for the developer. It's not a great deal for the user.

We've made a different choice. When we instrument our software, we ask a different question first: what do we actually need to know, and what's the minimum data required to know it?

That question changes everything downstream.

What "privacy-first" means in practice

It means choosing tools that are designed around data minimisation rather than data maximisation. It means configuring those tools to collect less, not more, even when collecting more is the default. It means not storing IP addresses when aggregate counts tell us everything we need. It means respecting the fact that the people using our software didn't sign up to be subjects of a data collection exercise — they signed up to use a product.

It also means being honest about the tradeoffs. Privacy-first instrumentation gives us less granular data. We can't reconstruct individual user sessions. We can't track people across devices or match behaviour to identities. We've accepted that limitation because we think the alternative — treating every user as a data point to be harvested — is incompatible with building software we'd actually want to use ourselves.

The tools we chose

We use Aptabase for in-app analytics, Umami for web analytics, and Sentry for error monitoring. All three can be configured to respect user privacy seriously. None of them require you to do so — that's a choice.

In an upcoming post, we'll walk through exactly how we've configured each one: what we collect, what we deliberately don't collect, and why.

"Built with care" as a commitment

The tagline exists because it describes something real. We build slowly and deliberately. We choose tools that reflect our values. We think about the people on the other side of our software as people, not sessions.

Privacy is part of that. Not a feature, not a compliance checkbox — a consequence of caring about what we're building and who we're building it for.

Heldcraft builds privacy-first software for users who notice. Pre-launch, building in public.

Garry Tan is President & CEO of Y Combinator. He is also, apparently, shipping 10,000 to 20,000 lines of production code per day as a side activity.

That number sounds like marketing copy. It might not be.

Tan open-sourced his setup last week: gstack, a collection of 15 Claude Code slash commands that turn a single AI session into something that behaves like a staffed engineering team. His last 7-day stat from the README: 140,751 lines added, 362 commits, ~115k net LOC. While running YC.

I spent time with it this week. Here's what it actually is.

What gstack does

The core idea is role-based cognitive specialisation. Instead of prompting Claude Code generically, gstack gives it structured personas — each a slash command, each with a specific mode of thinking:

• /plan-ceo-review — reframes your feature request. Asks "is this the right problem?" before you write a line of code. Four modes: expand the scope, selectively expand, hold scope, or reduce.

• /plan-eng-review — produces architecture, ASCII data flow diagrams, a test matrix, edge cases, failure modes. Forces hidden assumptions into the open before you build.

• /review — the paranoid staff engineer. Finds bugs that pass CI but fail in production. Auto-fixes the obvious ones. Flags the judgment calls.

• /qa — opens a real Chromium browser, clicks through your actual app, finds bugs, fixes them with atomic commits, generates regression tests.

• /ship — syncs main, runs tests, audits coverage, pushes, opens a PR. Bootstraps test frameworks from scratch if you don't have one.

The full list is 15 commands. They're designed to chain: plan with CEO + eng + design, build, review, QA, ship. One feature, seven commands, complete.

What actually matters here

The interesting thing about gstack isn't any individual command. It's the governance layer.

Running Claude Code without structure gets you fast iteration but unpredictable quality. The failure mode is vibe coding — moving quickly, making decisions in the moment, shipping things that work until they don't.

gstack solves this by introducing review gates. The CEO command rejects 3-star features before you build them. The eng review locks in architecture before you write code. The design review catches AI slop before it ships. The QA step verifies fixes actually work.

That's not a coding tool. That's a process. And it's a process that scales with parallel sessions — Tan runs 10+ simultaneous Claude Code instances, each in its own branch, each with the right cognitive mode for the task.

One person, ten parallel agents, structured roles, real review gates. That's the actual innovation.

What I'm taking from it

I run a small agent pipeline at Heldcraft — six specialist agents (product, architecture, dev, QA, security, release). The pipeline design predates gstack but the philosophy is the same: specialisation beats generalism for structured work.

A few things from gstack I'm actively looking at:

/qa and real browser automation. The ability to open a real browser, interact with a staging URL, find a bug, fix it, generate a regression test, and verify the fix — in one command — is a genuine capability unlock. Right now my QA infrastructure doesn't have browser access on the server. That's a concrete gap to close.

/review with auto-fix + flag-for-human. The pattern of "fix the obvious, flag the judgment calls" is exactly what automated PR review should look like. Currently my security review step flags everything and asks for human review.

/document-release. A command that reads every doc file in the project, cross-references the diff, and updates everything that drifted. This is the unglamorous work that never gets done. Automating it would close a real gap.

The honest caveat

140k lines in 7 days is an extraordinary claim. I have no way to verify it, and lines of code is a notoriously bad metric. What matters is whether the output is useful and correct.

What I can verify: the tooling exists, it's well-designed, it's MIT licensed, and the pattern of structured AI-assisted development it represents is real. Whether any specific individual is hitting those numbers is less interesting than whether the ceiling is higher than most people think.

The answer to that second question seems clearly yes.

I'm building Heldcraft — a software studio focused on lean, agent-assisted development. This is part of my ongoing experiment with agentic systems.

For years, building a mobile app meant accepting Apple's deal: give us 30% of every subscription, every purchase, every dollar your users spend. That was the cost of distribution.

That deal has changed.

In 2025, the Supreme Court upheld the Epic v. Apple injunction. Apple must now allow developers to direct users to alternative payment methods. In the EU, the Digital Markets Act arrived first. The result is the same: the 30% cut is no longer mandatory.

I spent some time this week looking at ZeroSettle — a YC-backed SDK that operationalises this right. The pitch is straightforward: swap Apple's 30% for their 5% + 50¢, keep the difference, let users pay less.

Here's what I actually found.

The user experience question

My first question was: how much friction does this add for users?

The answer, at least in the US on iOS, is: less than I expected.

ZeroSettle presents a native-feeling bottom sheet inside your app. Apple Pay is the primary option. Card entry is the fallback. Users never leave the app. On a warm load it opens in under a second. It looks and feels like a standard StoreKit sheet — Stripe under the hood, not that users would know.

Outside the US, it degrades. EU users get an in-app browser or Safari — a noticeable context switch. Android opens a full-screen WebView Activity, rougher than iOS. The product is clearly optimised for US iOS first.

The friction delta in the US: minimal. If your user has Apple Pay set up, it's one Face ID tap, same as StoreKit.

Do you still have to offer the App Store?

Yes — but you can demote it.

Apple's current rules require that StoreKit remain available as an option when you're using the External Purchase entitlement. You can't block it entirely. But you can:

• Present direct billing as the primary button with the App Store as a smaller secondary option

• Offer a discount for going direct ("Subscribe and save 15%")

• Run campaigns that migrate existing App Store subscribers over time

ZeroSettle handles the compliance automatically — the required Apple disclosure modal, jurisdiction detection, silent fallback to StoreKit outside the US and EU. You write a few lines of code and the SDK figures out the rest.

The math

On $1M ARR with 75% of users migrating to direct billing and a 10% discount incentive to make the switch worth their while:

• Without ZeroSettle: Apple keeps \(300K (30% of \)1M)

• With ZeroSettle: You pay ~\(112K (discount + ZeroSettle fee) instead of \)300K

• Net extra profit: ~$188K/year

The calculator on their site is worth playing with. The economics are compelling at any meaningful scale.

At small scale — say, $50K ARR — the absolute numbers are smaller but the margin improvement is the same. 25 percentage points of net margin is 25 percentage points regardless of revenue size.

What I'd watch

ZeroSettle is early. They just launched on Product Hunt. The legal framework they're operating in is new — the Epic injunction only took effect in 2025 and Apple is still testing what they can push back on.

The compliance story is good but it's worth monitoring. Apple has a history of finding ways to make alternatives less attractive (see: Apple's 27% link-out fee, which Apple introduced post-injunction and was forced to remove in 2025). The DMA in the EU has seen similar friction.

That said: this is not a loophole. It's a court order and a legislative requirement. The direction of travel is toward developer rights, not away from them. Hundreds of major apps already offer external billing. This is becoming standard practice, not early-adopter territory.

If you're building a mobile subscription product, it's worth at least running the calculator and understanding what you're leaving on the table.

I'm building Heldcraft — a software studio. This is part of my ongoing research into tools and trends relevant to mobile and SaaS product development.