The Developer Seat: Figaro Builds Software Into Your Company
The developer seat is an AI seat that builds software into your company — integrations, internal tools, storefront features, custom Shopify apps — with the same accountability as every other seat: a plan, a budget, an approval, and a measured outcome.
Published August 15, 2026
The developer seat is an AI seat that builds software into your company — integrations, internal tools, reports, storefront features, custom Shopify apps — with the same accountability as every other seat: a plan, a budget, an approval, and a measured outcome. If AI can build it, your company can have it as a seat. The deliverable is different — software instead of campaigns — but the discipline is identical, and the discipline is the point.
The rent you are paying for features
Open your app admin and count the subscriptions. Most brands at the $1–10M stage pay monthly for a stack of single-feature software: a landing-page builder, a schema plugin, a survey tool, a subscription widget. Each one solved a real problem on the day it was installed. Each one is now rent — a small standing tax that never ends and never compounds in your favor.
This is the developer seat's first job, and we have run it on ourselves. The case-study brand — the working company Figaro is dogfooded on — had 7 paid Shopify apps recoded native to the storefront, landing pages, schema, surveys, and subscription widgets among them, and the subscriptions deleted. The app-fee overhead was cut alongside a platform-tier downgrade worth $2,101/mo (as of August 2026). To be fair to the apps: some are worth every dollar. A deep review platform or a real subscription engine is a product, not a feature — those stay, and the seat wraps them with a chair and a report card instead. The seat kills the single-feature rent. It does not pretend everything is single-feature.
Lovable builds you an app. Figaro builds your company a capability.
The vibe-coding platforms answered "can AI build software?" — yes, decisively, and it is commoditized. Give them credit for that; it is a real change. The question they structurally cannot answer is "can software be built INTO a company?" Their output is an orphan at deploy: no company context, no maintenance owner, no measurement, no idea what your margins or policies or history are. The developer seat's output is born wired — it reads the company record, respects the one gate, carries an owner-seat and a health check, and is graded on the ledger like every other seat's work. The same prompt produces generic software there and your software here, because the seat drafts against your record. They generate software. We staff it.
None of this makes the generators enemies. They are engines a developer seat can use as hands — generate with one, then wire, gate, and own what comes out. Chairs for them too.
What the seat builds
The scope is a ladder, and the same autonomy rungs apply at every level:
- Integrations and data pulls — wire a data source into your business record instead of buying another tool that almost fits.
- Internal tools and automations — the "I need a thing that does X" class: reports, dashboards, small workflows. Draft, gate, ship, then measure whether anyone uses it and what it moved.
- Storefront features and custom apps — landing pages, native replacements for rented widgets, small customer-facing builds.
- Wrap-a-tool seats — any external product you pay for gets a chair and a report card, so the tools you keep are accountable too.
The rails
Software is code with blast radius, so the rails are non-negotiable. Measurement at birth applies to builds: every proposal states the metric it will move, the adoption check, and the measure-by date — "we shipped it" is not a verdict; "it's used and it moved X" is. Deploys are gated actions, exactly like spend and publishing: nothing reaches production without a human clearing it at the gate. And every build carries an owner-seat and a health check, or it does not ship — no orphan software, ever. On price: the seat is included in the instance's unlimited AI seats, with model tokens at cost to whoever holds the key.
The shortest way to say all of this: the missing integration is not a feature request on someone else's roadmap. It is a ticket to your developer seat.
Questions founders ask
- Can Figaro build custom Shopify apps?
- Yes. Storefront features, landing pages, internal tools, integrations, and custom Shopify apps are all inside the developer seat's scope. Every build follows the same discipline as every other seat's work: a proposal that states what it will move and by when, a human approval before anything deploys, and an owner-seat with a health check after it ships. One honest boundary: a large one-off, agency-scale build is a services engagement, priced as one. The seat owns the continuous stream of small builds a business actually generates — the missing integration, the internal report, the widget you are renting for $40 a month.
- How is this different from Lovable or Replit?
- Lovable and Replit answered "can AI build software?" — yes, and it is commoditized. The unanswered question is "can software be built INTO a company?" Their output is an orphan at deploy: no company context, no maintenance owner, no measurement. The developer seat's output is born wired — it reads the company record, respects the one approval gate, carries an owner and a health check, and is graded on the outcome ledger. Lovable builds you an app; Figaro builds your company a capability. And the generators are not enemies: they are engines a developer seat can use as hands, then wire, gate, and own what comes out.
- What does custom software from Figaro cost?
- The developer seat is included in an instance's unlimited AI seats — there is no per-build fee for the seat's work. Model tokens are billed at cost to whoever holds the key, and big builds burn real tokens, which per-seat attribution makes visible rather than hiding in a markup. The exception is scale: if a build is genuinely agency-scale — months of work, a product in its own right — that is a services engagement priced as one. The seat handles the continuous small-build stream, not one-off $30K projects.
- Who maintains what the developer seat builds?
- The seat that built it. Every build carries an owner-seat and a health check, or it does not ship — that is a hard rail, not a preference. This is the specific failure of generated software elsewhere: it works on the day it deploys and then nobody owns it when the API changes or the edge case arrives. In Figaro there is no orphan software; the thing that wrote the code is also the thing that watches it, and its health shows up on the same board as everything else.
- Can it replace the apps I'm paying for monthly?
- Many of them. Most brands pay monthly rent for a stack of single-feature apps, and the developer seat can recode much of that stack native to the storefront and delete the subscription. The case-study brand had 7 paid Shopify apps recoded native — landing pages, schema, surveys, and subscription widgets among them — with app-fee overhead cut alongside a platform-tier downgrade worth $2,101/mo (as of August 2026). The honest caveat: some apps are worth keeping. A deep product with real infrastructure behind it stays — the seat wraps it with a chair and a report card instead. What the seat kills is the single-feature rent.