Stacktora - Define once, run anywhere.

1/ Shipped something today I actually think matters: stacktora mcp

Your AI agent can now read, scaffold, audit, and install stacks directly — no shell-out, no text parsing, no separate service to babysit.

Zero VCs. Infinite spite. Still building alone. 🧵

2/ The lazy version of this feature is a hosted remote MCP server.

The problem: an agent scaffolding a project has to write files to YOUR disk. A server sitting on my box can't touch your laptop. So "remote" was never actually an option — it just took me admitting that.

3/ So instead of standing up new infra, I bolted an MCP server directly onto the CLI you already have installed.

Same package. Same version. Same battle-tested engine that's been generating real projects for weeks. npx -y stacktora mcp and you're done.

4/ 10 tools, one per existing command: read · init · install · recipes · sync · check · plan · audit · doctor · status

If your agent can already run the CLI, it can now do the exact same things without you translating its output back into text for it.

5/ Didn't just write this and hope. Tested every path before shipping:

✅ install → read → sync → verified 12 real files hit disk
✅ a real policy violation, correctly caught
✅ unknown recipe, already-exists, unknown tool — all fail clean, nothing crashes
✅ malformed input on stdin — ignored, not fatal
✅ no Docker installed — degrades gracefully instead of exploding

6/ The unglamorous part nobody tells you about building on MCP: stdout IS the transport channel.

Every existing CLI command prints colored text to stdout. Wire those in directly and you corrupt your own protocol the first time anything prints.

So none of the existing commands got touched. Every tool is a fresh function returning data, not text. Old CLI: 100% untouched. New surface: fully additive.

7/ This is Pillar 2 of the whole reason Stacktora exists — agents reading your actual config instead of guessing at it from vibes and file-scanning.

Compliance dashboard did the "make sure it's still true" side. This does the "let the agent act on it" side.

8/ Bootstrapped. Solo. No roadmap committee. Just shipped it because it needed to exist.

npm i -g stacktora → stacktora.com

#buildinpublic #solofounder #bootstrapped #indiehackers #devtools #MCP

1/ Shipped every item on the roadmap tonight, and found 7 real bugs along the way. Long one — worth the read if you build alone too.

Zero VCs. Infinite spite. Still shipping. 🧵

2/ Started by actually using Compliance on something real instead of demo repos.

Built a small real project from scratch (pingcheck, a URL uptime monitor) using my own CLI to scaffold it. Real tests. Real CI. Real branch protection. Pushed, wired up, verified live.

Dogfooding your own tool on a throwaway demo isn't dogfooding. This was.

3/ That real usage immediately found a real bug: the Compliance dashboard's own copy-paste CI snippet had the wrong input name. Told everyone to pass token: when the action actually expects stacktora-token:.

The action silently ignores inputs it doesn't recognize instead of failing — so CI ran green while quietly reporting nothing. Anyone who copied that snippet before today was silently broken and had no way to know.

Fixed at the source. Confirmed by fetching the real action.yml directly, not assuming.

4/ Shipped Notifications — Slack + email the moment a repo that was passing starts failing. Not on every failing run after (spam), not on a repo's first-ever report (nothing to compare yet).

Hardened it defensively too: every new query degrades to safe defaults if the migration hasn't run yet, since this fetch sits inside the dashboard's one big data-load call. One migration-ordering mistake here and the WHOLE dashboard breaks, not just this section.

5/ Shipped stacktora mcp — an actual MCP server, built into the CLI you already have. No new service, no new hosting.

10 tools. Read, scaffold, audit, recipes — full parity with the CLI. Published to npm.

The unglamorous detail: stdout IS the MCP transport. Wire the existing print-oriented commands straight in and you corrupt your own protocol the first time anything logs. Every tool is a fresh function returning data instead.

6/ Tonight I actually tested it with a live agent instead of just my own sandbox.

Real find: it correctly refused to guess which project I meant when the path was ambiguous, found the CLI installed via npm on its own, ran stacktora check, escalated to stacktora plan on its own initiative to get the real diff instead of stopping at a summary.

Correctly reported: only drift was a stale timestamp field. Zero actual config drift. That's exactly right, and it said so instead of alarming me over nothing.

7/ Closed 4 real gaps in the recipe catalog: Auth/SSO starter, GraphQL API, LLM Gateway/Proxy, Job Queue & Scheduler. Things every recipe before this assumed you'd build yourself.

Validated every one against the real live schema. Then actually ran them through the real generator — which caught bug #7: two of the four don't need custom env vars (totally normal, schema-valid case), and generating either one crashed the engine outright. config.env has always been optional. Nothing ever guarded for its absence.

Fixed at the source, not patched around.

8/ Pushed the site's own codebase to a real Git repo for the first time tonight too. No more living only on the server.

Small thing. Overdue thing. Done thing.

9/ Bootstrapped. Solo. No committee greenlighting any of this.

Just a long night of building the thing, finding what's actually broken, and fixing it instead of shipping around it.

stacktora.com

#buildinpublic #solofounder #bootstrapped #indiehackers #devtools

1/ Added 9 real recipes to the Vault today, not 9 variations of the same thing:

Multi-tenant SaaS · Webhook ingestion · Ledger/double-entry accounting · Media processing · API gateway/rate limiter · Mobile BaaS · Notification dispatch · Search-as-a-service · Centralized logging/metrics

37 total now. Bootstrapped, solo, still shipping. 🧵

2/ The bar for "does this deserve a recipe": is this a pattern people build from scratch, badly, under time pressure — every single time?

Webhook ingestion is the clearest example. Everyone's first version has no idempotency, no signature check, no retry queue. Then a duplicate Stripe event double-charges someone and it gets rebuilt correctly, in production, on fire.

That's a recipe now. Idempotent, signature-verified, Redis-backed queue + worker.

3/ Ledger & Double-Entry Accounting is the one I'm most opinionated about.

It is NOT a payments recipe. It doesn't touch Stripe. It's for tracking where money actually went once you have it — marketplaces splitting payouts, internal balances, anything that needs to survive an audit.

Different problem than "take a payment." Treated as one for too long, everywhere.

4/ Two brand new categories: Notifications and Search.

Notification Dispatch is the outbound twin to the Webhook recipe's inbound — unified email/SMS/push, queue + worker, retry-safe.

Search-as-a-Service is just: stop bolting a slow ILIKE query onto your main database and calling it search. Meilisearch in front of Postgres, actually fast, actually typo-tolerant.

5/ Every recipe gets schema-validated against the real live schema, then actually run through the real generator before it ships — not just "the JSON looks right."

Caught real bugs doing this before. Won't stop doing it because a batch is bigger.

6/ No roadmap committee decided any of this. Just looked at what's actually missing and built it.

stacktora.com/vault

#buildinpublic #solofounder #bootstrapped #indiehackers #devtools

The Real Force Multiplier: company.stacktora.json

At scale, the real power is enforcing standards across every repo, every new hire, and every AI agent touching your codebase.

Internal platform teams already try to build this by hand at every company that reaches a certain size. They do it badly, inconsistently, and with massive overhead. Stacktora gives them a single source of truth that every repo references.

One company.stacktora.json defines:

• Approved runtimes and versions

• Standardized service configurations

• Security and compliance requirements

Every new repo, every new hire, every AI agent starts from the same foundation. No drift. No exceptions. No "but my project is special."

Stacktora.com
Stacktora.com/vault

In 2026, it seems every new startup is "AI-native" or "agentic." Stacktora chose a different path — not because we ignore AI, but because we see the real opportunity beneath the hype.

The "obvious" AI agent ideas are already crowded. The first wave of AI agent startups followed a predictable pattern: take a repetitive workflow, add an LLM, call it an agent. Most discovered the same problem: the workflow wasn't defensible, and a foundation model update shipped the same capability for free. The ideas worth building are the ones where the agent owns something the foundation model can't replicate: proprietary data, regulated workflow access, or deep domain expertise.

Enterprises are chasing agentic AI — but few have caught it. According to Forrester, three‑quarters of enterprise leaders say they're adopting agentic AI, but only a small minority have moved beyond pilots into meaningful production. Governance remains immature, platform strategies remain fuzzy, and ROI is still elusive. "Agent‑washing" is rampant: 84% of enterprise leaders encounter products marketed as "agents" that are actually sophisticated chatbots, and 88% say this has eroded trust in AI broadly. The top barriers cited — hallucinations (43%), security (42%), and accuracy (40%) — all point to the same problem: agents that behave unpredictably.

Stacktora is the foundation AI agents need to run reliably. AI coding agents need a reliable, machine‑readable definition of your stack — a stacktora.json they can read instead of guessing from scattered config files. More accurate prompts, fewer hallucinations, less wasted compute. The more AI writes code, the more essential reproducible environments become.

We're building the infrastructure the AI era needs. When AI agents become a commodity, the standards that define how they work will be the real long‑term value. Investors who've watched AI companies burn cash want payback periods under 18 months and differentiation that doesn't depend on tech novelty alone. Predictable revenue models and lower costs make financial forecasting far more reliable.

Stacktora's moat isn't a model that could be obsolete next quarter. It's a workflow that teams depend on: define once, generate everywhere, zero lock‑in. The most defensible positions involve data that accumulates over time, making the product more valuable the longer a customer uses it.

In 2026, an "AI‑resistant" business isn't anti‑technology — it's one whose core value can't be automated away, and ideally one that benefits when AI gets cheaper and more abundant. Stacktora is exactly that: the shovel seller in the gold rush, the foundation AI agents depend on. We're not competing with AI. We're making it work.

Stacktora.com