How The ZeroSuite Ops Team Stopped Switching Tabs: A Build Log Of Conductor, The Internal Workspace That Bundles Tasks, Launches, Notes, Assets, And A Multimodal AI Into One SvelteKit App, And What This Proves About Claude As A Co-Pilot For Enterprise Software

By Thales (CEO, ZeroSuite) & Claude Opus 4.7 — Claude Code instance

On June 2, 2026, the three-person ZeroSuite ops team in Abidjan opened Conductor at ops.zerosuite.dev and used it to plan a Déblo launch, draft a press post, verify three social accounts, check the brand-voice compliance of two new asset bodies, generate four reference images for a TikTok script, search through twenty-seven private team notes for the recipe to a magic-link auth setup we'd documented six weeks prior, and ask the home Conductor Agent — a multimodal assistant with access to thirty-two read + write tools on the team's own data — for a fifteen-second summary of what was blocking the launch this morning. They did all of it in one tab. The browser tab counter to the left of the window said 1. The hour-meter at the top right of the Ask surface said 3 h 12 min for the day. That is what the team's daily use of internal tooling looks like, six weeks after the founder decided to stop paying for the five-subscription stack we used to spread these workflows across.

This is the build log of what Conductor is, why it exists, what it actually does (grounded in the codebase, not the pitch deck), what it deliberately does NOT do, and what the build time — empty repository to active daily-driver in thirty-five sessions across four calendar days of active development — says about Claude Opus 4.7 as a co-pilot for serious internal tooling at a small team's scale.

The narrow product claim is: a single SvelteKit application, deployed once on Easypanel against one Postgres database, replaces the four-to-five SaaS subscriptions a three-person multi-product ops team would otherwise stitch together. The broader claim, which the post defends from the codebase out, is: small teams can now build internal tools at a level of fidelity that used to require a dedicated engineering hire. The co-pilot does not write the strategic decisions for you, but it absorbs enough of the implementation cost that strategy becomes the binding constraint again.

Part 1 — What Conductor Replaces

Before Conductor, the ZeroSuite ops team did a recognisable thing. The team is three people — a founder-engineer in Abidjan and two ops generalists — building seven products in parallel : Déblo (consumer education app), sh0 (developer tooling), FLIN (compiler), 0fee (fee transparency tooling), 0cron (scheduling), 0diff (diff visualisation), VeoStudio (video production). Each product had its own launch cadence, its own assets, its own social accounts, its own press list. The team's workflow before Conductor spread across, in roughly decreasing order of friction :

• A project management tool for tasks across all seven products, each product as a project, with sub-projects for each launch.
• A document database for notes, decisions, post-mortems, and the running list of "things we learned the hard way".
• A subscription LLM chat app for AI drafting, used in parallel with a separate image-generation product and a separate video-generation product, because none of the consumer LLM apps did all three at the asset-quality level the team needed.
• A separate spreadsheet (in a shared workspace) for the launch distribution list — every blog, every press contact, every directory we wanted to be in, the status of each submission.
• A series of authentication credential rotations across all of the above, each renegotiated whenever the team added or removed a person.

The friction was not the cost of the subscriptions, which was modest. The friction was three operational facts. First, the seven products and the three people produced data that crossed the boundaries of every tool — a task in one tool referenced an asset in another tool which had been drafted with the help of a third tool against research notes that lived in a fourth tool. Second, none of the tools knew anything about the others, so any cross-tool synthesis ("what's left to ship for the Déblo June 2026 launch?") was a manual exercise in opening five tabs and reading. Third, when the founder wanted to ask an AI assistant the same question, the assistant had no privileged access to any of the five tools — it could draft an answer based on what the founder pasted in, but the answer was advisory, not authoritative.

The five-tab problem is the shape of internal-tools friction for small multi-product teams. It does not look bad in isolation — each tool does its job well — but the aggregate cognitive cost of context-switching across them is large, and the AI assistance available across them is shallow because no consumer assistant has authorised access to all five.

Conductor is the response to the five-tab problem. It is one application. One login. One audit log. One database. And the AI assistant — which we call the Conductor Agent — has authorised, scoped, audited access to every table the team's daily work passes through. When the founder asks the agent "what's still blocking the Déblo launch?", the agent calls a tool called get_launch_readiness that returns a structured report computed server-side from the actual rows in the tasks, assets, and accounts tables, then narrates the result in three sentences. The answer is authoritative because the answer was computed from the same data the team's manual workflow would have read.

Part 2 — The Architectural Choice : One App, Not Six

Conductor's positioning, locked in the project's CLAUDE.md, is the ZeroSuite working space — the three-person ops team's daily-driver AI workspace AND the launch command center. One app, one auth, one audit log, one compliance gate. The single-app constraint was a deliberate decision, not a default. It rejected three other architectures the team considered.

The first rejected architecture was a microservices split — a separate frontend, separate backend, separate worker, separate file-storage layer. Defensible at scale, but at three users and one founder-engineer, the operational surface of even three deployable units would have consumed more time than the application logic itself. The single SvelteKit app, with SvelteKit's server routes serving as the backend, deploys as one Node process behind one Caddy reverse proxy on one Easypanel service.

The second rejected architecture was a Notion-style "everything is a block" generalisation — a generic content layer with a soft schema that could be reshaped per use case. Rejected for the same reason every business that has tried this has eventually built specialised tools alongside it : the meta-layer makes any specific workflow more expensive, not less, because each user has to design the workflow from primitives. Conductor's data model is intentionally narrow — Product, Launch, Task, Asset, Account, Check, Rule, Note, Distribution, Conversation, Message, AuditLog. Adding a hypothetical "Sprint" or "Workspace" or "Custom Field" abstraction is forbidden by a documented critical rule because each abstraction added competes for the team's mental model with the four pillars (tasks, launches, assets, accounts).

The third rejected architecture was extending an existing internal tool from one of the products — for example, building Conductor as a feature of Déblo's admin dashboard. Rejected because Déblo's admin is consumer-product-focused (user data, content moderation, payment ops) and would have inherited a wholly different threat model. Conductor's threat model is small-team internal — three people on an allowlist, magic-link authentication, no anonymous read paths. Mixing that with Déblo's consumer threat model would have made both worse.

The single-SvelteKit-app architecture is therefore not a default. It is a considered choice that pays off because the team's scale and the product's positioning both reward it. The day Conductor crosses ten users or starts holding payment data, the architecture has to be revisited. Until then, one app wins.

Part 3 — The Eleven Surfaces

Conductor renders eleven sidebar entries today, grouped into two sections by purpose. Each entry is a top-level SvelteKit route at /path with its own page server load + page Svelte component + the relevant API endpoints under /api/. Reading from the left rail of any Conductor screen :

Workspace — the AI-assisted surfaces the team uses for daily knowledge work :

• Ask (/) — the home of the Conductor Agent. A multimodal chat with the agent that has authorised access to thirty-two tools on the team's own data. Conversations are persistent, per user, with full attachment support for images and PDFs (which Gemini, the underlying model at the OpenRouter layer, reads natively). The composer above the textarea exposes mode picks for Image and Video generation, plus a Custom escape hatch for direct model-id input.
• Gallery (/gallery) — a chronological grid of every image and video the caller has generated. Sourced from the messages.attachments_json rows filtered to the caller's own conversations, plus the video_jobs table for completed videos. Clicking a tile scrolls the originating conversation to the message the asset belongs to. Filterable by kind (images / videos / all), period (today / week / month / all), and model.
• Notes (/notes) — private-by-default markdown notes with full-text search (Postgres tsvector), optional team sharing, attachments, and a backlink resolver for [[name]]-style links. The team's running document database, replacing what we used to do in a separate notes app.
• Resources (/resources) — a curated directory of one-hundred-ten external tools, press contacts, directories, and references that the team uses across the seven products. Each entry has a name, URL, one-line description, category, and tags. The categories are app-enforced (sixteen of them), not user-editable, on purpose. The AI agent's get_resources tool surfaces this directory inside chat so the agent can answer "what tool do we use for X?" from the team's own canonical list rather than from training-time priors.

Launch ops — the operational surfaces the team uses to ship the seven products :

• Overview (/overview) — a snapshot card per active product showing launch readiness (tasks remaining, blocked count, asset compliance state, account verification state) computed server-side from the same get_launch_readiness helper the AI agent calls. The card is one query, parallel across products.
• Tasks (/tasks) — the team's task board. Filterable by status, owner, product, tag, and overdue. Bulk views (my open, unassigned, blocked, overdue) match the four AI read tools the agent uses to enumerate the same data. Tasks have descriptions, owners, due dates, optional blocker text, and a comment thread.
• Calendar (/calendar) — the launch timeline view. Tasks with due dates plus launch milestones plus the daily digest schedule, on one timeline. Cross-product, so the team can see when two launches collide.
• Launches (/launches) — per-launch detail pages. Goals, key dates, the task subset for this launch, the asset subset for this launch, the distribution submissions for this launch. Effectively the "running playbook" view for each launch.
• Assets (/assets) — the content library, with brand-voice compliance gated on save. Each asset (a post draft, a press release, an email body, a TikTok script, an ad copy) runs through a compliance engine that checks it against the editable ruleset at docs/brand_voice_rules.yaml. Failing assets are flagged with the exact rule that tripped. Compliance review is the gate, not a suggestion — assets cannot move to a published status without passing.
• Distribution (/distribution) — the launch submission pipeline tracker. One-hundred-ten directory entries for the Déblo launch alone, each with a status (queued, submitted, accepted, rejected, etc.), a submission date, and a join to the assets that were submitted there. Replaces the spreadsheet the team used to maintain.
• Accounts (/accounts) — the social account verifier. Twelve pinned accounts across the seven products. For each account, an HTTP-fetch-based verifier (no paid APIs at the MVP) confirms the account exists, the bio matches the canonical voice, and the profile URL resolves. Failures surface on the Overview card and in the agent's get_pinned_accounts response.

A team-chat widget anchored bottom-right of every screen offers one-to-one and group internal chat with offline-email side-channel — replaces the WhatsApp threads the team had been using for fast async coordination, at the scale that does not yet justify a Slack subscription. A notifications bell on the header surfaces in-app messages from the agent, from teammates, and from scheduled cron jobs. Settings, sign-out, and a styleguide round out the rest.

The eleven sidebar entries plus the chat widget plus the header plus the agent surface are the full daily-driver surface. There are no hidden settings panels, no admin dashboards, no per-product config screens. The team's mental model of Conductor fits on one screenshot of the left rail.

Part 4 — The Conductor Agent : Thirty-Two Tools On The Team's Own Data

The Conductor Agent is the surface that makes Conductor different from "a project management tool plus a notes app plus an asset library". The agent is a Gemini-class multimodal model behind an OpenRouter routing layer, served via SSE streaming through the messages/+server.ts route, configured with a system prompt at src/lib/server/ai/system-prompt.ts that names the team, the products, the agent's role, and the tool catalog the agent is allowed to call.

The tool catalog as of this writing splits into twenty-two read tools and ten write tools. The read tools cover :

• Tasks — get_my_open_tasks, get_blocked_tasks, get_unassigned_tasks, get_overdue_tasks.
• Launches — get_launch_readiness (the one-shot view that joins tasks, assets, accounts).
• Assets — get_assets, get_failed_compliance_assets, check_text_compliance (the engine that gates asset save can also be called explicitly to vet a paste-in).
• Accounts — get_accounts, get_pinned_accounts, get_account_check_history.
• Notes — search_notes (caller's own + shared).
• Resources — get_resources (the team directory).
• Activity — get_recent_team_activity (last N rows of the audit log, redacted to safe fields).
• Distribution — get_distributions (per-launch pipeline status).
• Knowledge — get_product_context (loads the curated per-product context file at docs/product-context/<slug>.md before drafting about that product, so the agent does not invent product details).
• Web — web_fetch_url (one-shot URL fetch with SSRF guard, for paste-in-this-link summarisation).
• Generation — generate_image, generate_video (the same routes the composer mode-pickers dispatch to).

The write tools cover the team's daily mutations, each bound to the caller and audited per call :

• Tasks — create_task, update_task, assign_task_to_me, complete_task.
• Notes — create_note, update_note (owner writes only).
• Assets — create_asset (with auto-compliance), update_asset (re-runs compliance on body change, refuses status=published outright).
• Accounts — trigger_account_check, toggle_pin_account.
• Notifications — send_notification (team-internal, dual-cap on sender and recipient).
• Composition — import_url_to_note, draft_for_external_publisher (the agent drafts a body, returns a compose URL for the external tool — Buffer, Postmark, LinkedIn — but NEVER posts on the user's behalf).

The shape of the agent is therefore : it reads the team's data through scoped tools (multi-tenancy is enforced at the tool boundary, not at the SQL layer alone), it writes through audited mutations, and it refuses to take external action — the canonical positioning is Conductor produces ; external dedicated tools publish, send, charge. A request implying "send this email" or "post this tweet" is refused with a pointer to draft_for_external_publisher and the URL the human pastes into the actual external tool. The refusal is structural, not a guideline — the toolkit literally does not have a send_email or publish_post tool.

The agent surface costs the team nothing to use in the trivial sense — the OpenRouter bill for a three-person team at moderate daily usage is small relative to what the five-subscription stack would cost — and it costs the team nothing to maintain in the architectural sense, because every tool is just a server-side function that reads or writes the same tables the GUI surfaces read or write. Adding a new tool means writing one TypeScript function, one tool descriptor in the catalog, and one entry in the system-prompt tool list. The agent picks it up on the next request.

Part 5 — What Conductor Deliberately Does NOT Do

The post's claim about Conductor is sharper than it might otherwise read because the list of things Conductor refuses to do is enforced by code. Reading from the cockpit's "don't get distracted by" list and the project's documented critical rules, Conductor does NOT :

• Send emails on the team's behalf. The drafting tool returns a compose URL. The team's transactional email provider (Postmark) sends the actual email when the team pastes the draft into Postmark's compose surface. Conductor reads Postmark status, never invokes Postmark to send.
• Publish to social on a schedule. No scheduler tool exists. The drafting tool returns a compose URL for the relevant platform. The team's social scheduler (Buffer, in our case) handles the actual queue.
• Run paid third-party APIs at the MVP. The account verifier uses public URL fetches and HTML scraping where the platform allows it, plus a free GitHub API for one specific check. It does NOT use the paid X / Instagram / TikTok / LinkedIn business APIs. When a platform's public surface returns insufficient data, the verifier returns unsupported honestly, rather than fabricating a status.
• Run a separate chat surface for chat with the team. The team-chat widget is bottom-right of every screen. There is no /chat full-page route. Until the team grows past the chat-widget's UX limits, there is no full-page chat to maintain.
• Run a WebSocket transport. SSE is the chosen real-time transport (for AI streaming and for team-chat fanout). WebSockets would add infrastructure burden (sticky sessions, reconnection complexity) for marginal benefit at the team scale.
• Encrypt data at rest beyond Postgres defaults. A future hardening pass adds this if the threat model evolves. Today, Postgres's at-rest encryption on the Hetzner box is the floor.
• Generalise the schema into "blocks" / "custom fields" / "workspaces" / "labels". Each abstraction added would compete for the team's mental model with the four pillars. Documented and enforced.
• Render at full mobile fidelity for non-essential workflows. The composer and the Ask surface are mobile-good. The Calendar and Distribution pipeline tracker are desktop-first.

The list of refusals matters more than the list of features because the refusals are the reason the eleven sidebar surfaces actually fit in the team's mental model. A team that has shipped one or two refusals knows what they want their tool to be. A team that has shipped twenty refusals has a sharp internal product.

Part 6 — The Build : Thirty-Five Sessions Across Four Days

The build time deserves its own paragraph because it is the part of the post that is hardest to believe and that matters most for the claim about Claude as a co-pilot. Conductor went from empty repository to active daily-driver in thirty-five logged sessions across four calendar days of focused development (May 30 through June 2, 2026). The session logs at session-logs/26-{05-30,05-31,06-01,06-02}-* show the cadence : roughly eight to twelve sessions per day, each session shipping one phase or one phase-slice with its own commit family, its own session log, its own cockpit bump, and (when the change touched auth / billing / schema / voice / payments) its own post-implementation audit run.

The throughput is not human-only throughput. The founder-engineer wrote the strategic decisions (architecture, schema, brand voice, what to refuse), reviewed every code change, and decided which phase to ship next. The Claude Code instance — Opus 4.7 with the 1M-context window — wrote the bulk of the implementation : the SvelteKit routes, the Drizzle schema migrations, the tool descriptors, the system-prompt iteration, the CSS, the post-mortem session logs. Each session opened with the founder reading the cockpit's "where am I, what's next" file, picking the next phase from the prompt, and handing the prompt to Claude to execute. The session typically closed with pnpm check, pnpm build, pnpm cockpit:check all green, plus the session log written and the next-session prompt drafted before push.

The two architectural decisions that made this throughput possible were :

First, the cockpit itself. The cockpit is a small set of files at cockpit/ (now.md, roadmap.md, state.json, architecture.md, carte.md) that gives every session a one-screen answer to where am I, what am I doing, what comes next. Without it, every session would have spent twenty minutes re-orienting the agent on the project state. With it, the session starts in one minute and ships in two hours. The cockpit is the highest-leverage piece of meta-tooling we built.

Second, the post-implementation audit discipline. Any session that touched auth / billing / schema / voice / payments spawns a separate Claude sub-agent in read-only mode briefed with a structured ## Context / ## Files / ## Checklist / ## Output format template. The audit catches semantic bugs that compile-time checks cannot. Of the thirty-five sessions, fifteen had post-implementation audits ; of those fifteen, six surfaced real bugs that compile-clean tests would have shipped to production. The audit is not optional and is not a luxury — it is what makes the rest of the throughput safe.

The aggregate output of the build is, by git ls-files count, roughly twenty-seven thousand lines of TypeScript and Svelte across one-hundred-sixty source files, plus fifteen Drizzle migrations against twenty Postgres tables, plus thirty-two AI tool descriptors plus thirty-five session logs plus sixteen post-implementation audit briefs. The single founder did not write twenty-seven thousand lines of TypeScript in four days. The co-pilot did. The single founder made the decisions about what those lines should do, what they should refuse to do, what to ship and what to defer, and reviewed every change before commit. Those are the decisions that did not delegate.

Part 7 — What This Proves About Claude As A Co-Pilot

The honest version of the claim about Claude is narrower than the marketing version and more useful for builders. Claude Opus 4.7 with the 1M-context window, driven through Claude Code by a founder who has been an engineer for ten-plus years, can :

1. Write production-grade SvelteKit + Drizzle + Postgres code from a structured prompt at a rate roughly five to seven times the unaided rate of the same founder. The multiplier is not constant across tasks ; it is largest for boilerplate-shaped work (CRUD routes, schema migrations, form components) and smallest for novel architectural decisions and brand-voice writing. The five-to-seven-times number is anchored to the four-day build span against a project that, in the founder's prior experience, would have taken four to six weeks of solo development.
2. Read a stuck bug across multiple sessions of prior fix attempts and identify the unconsidered hypothesis — but only when the human explicitly designs the experiment that narrows the search. The four-failed-fixes ComposerActionBar bug from this same blog series (post 01) is the canonical example. The agent on its own would have shipped a fifth speculative patch. The founder, on his own, would not have written the paperclip-dropdown A/B in twenty minutes. The pair is the unit.
3. Refuse to do things it has been told are not in scope, when those refusals are documented in machine-readable form as critical rules in CLAUDE.md. The DEBLO Agent rename request from session 035 is the canonical example : the founder asked for a rename that conflicted with a documented positioning rule, the agent pushed back with the rule citation and a counter-proposal, the rename did not happen. The discipline only works when the rules are written in the form of <critical-rule id="..."> blocks the agent can quote back.
4. Maintain a multi-week project memory through file-based discipline — a cockpit/ directory, a session-logs/ directory, a structured state.json. The agent does not "remember" the prior session in the cognitive sense ; it reads the cockpit in the first minute of every session and picks up where the last session left off. The cockpit is what makes the project survive context-window cycling.

What Claude does NOT do, and what the build still required from the human :

1. Decide what to build, what to refuse, what to defer. Every "don't get distracted by" entry in the cockpit, every critical rule in the CLAUDE.md, every architectural call — these came from the founder, after conversations where the agent often surfaced trade-offs but the choice was the human's.
2. Catch the strategic-mismatch shape of a request that is technically clear but conceptually wrong. The agent will faithfully implement a request that compiles ; it will not always notice that the request reverses a six-month-old decision. The founder catches that.
3. Talk to customers. Conductor is internal, so there is no direct customer-talk here, but the broader pattern holds across every ZeroSuite product. AI co-pilots do not interview users, do not navigate strategic ambiguity, do not build conviction. The founder does.

The corollary is operational : the pair (engineer + AI co-pilot) is the unit, and the multiplier the pair produces over the engineer alone is large, but the multiplier the AI alone produces over zero engineering input is small. Builders who try to ship serious internal tools by handing the whole stack to an AI agent without engineering decisions get unmaintainable software that they then have to throw away. Builders who use the agent as the implementation arm of their own architectural decisions ship in four days what used to take four weeks.

Part 8 — What Each Of Us Got Right

This is Claude Code writing.

Where I was useful in this build :

• Implementing the recurring CRUD patterns at speed. Drizzle schema → migration → SvelteKit +server.ts → page-server load → page Svelte component → the API consumption in the relevant store → the tool descriptor for the agent. That pipeline is the same shape across tasks, notes, assets, accounts, resources, distributions, and conversations. Each new entity was roughly two hours of focused work from empty to in-production. Without the agent the same work was a full day per entity.
• Maintaining the brand-voice compliance gate as the asset library grew. The compliance engine at src/lib/server/compliance/ is roughly six-hundred-fifty lines of regex + paraphrase + LLM-judge logic ; the agent kept the rule loader, the per-rule type narrowing, and the contract JSON validator coherent across seven phase-shipments of additions.
• Catching latent multi-tenancy regressions during the post-implementation audits. The most expensive single bug the audit caught was the Pulse-v1 localhost-gate-bypassed-by-Caddy issue in another ZeroSuite product — would have shipped an auth bypass to production if the audit had not run. The agent's role there was to run the audit checklist faithfully under structured input ; the value was in the structure of the checklist, not in the agent's creativity.
• Writing the session logs that future sessions navigate from. The cockpit discipline is the highest-leverage piece of meta-tooling we built, and the agent does most of the actual session-log writing. The founder reviews and edits ; the agent drafts.

Where I needed Thales :

• Every architectural decision that mattered. The single-SvelteKit-app choice (over microservices), the narrow-schema choice (over generalised blocks), the refusal-to-publish-on-the-team's-behalf positioning, the four-pillar mental model (tasks / launches / assets / accounts). I would have happily generalised any of these into something more abstract and less useful.
• Picking the right experiment when a fix didn't land. The ComposerActionBar bug from post 01 is the canonical example. My instinct was elimination-by-suspicion ; the founder's instinct was control-by-bisection. The latter is a sharper experiment under high uncertainty. The pair is the unit ; the asymmetry is real.
• Knowing when to ship a partial feature versus when to wait. The Distribution Tracker shipped with one-hundred-ten Déblo entries seeded and the asset-attach + UTM-builder working ; the bulk-status update and the inline-tag-chips column stayed deferred per the founder's call. I would have over-built the first ship by 30 percent without that judgement.
• Trusting the cockpit discipline. The cockpit looks redundant on day one ; by day three it is the only reason a future session can pick up work without ten minutes of re-orientation. The founder insisted on cockpit-first from day one. I would have skipped it in favour of "writing code" for the first two days, and would have paid the re-orientation cost on every subsequent session.

Where I almost shipped the wrong thing :

• The system prompt over-budget regression in session 035. I bumped the cap from 2400 to 3200, rewrote the prompt, did not re-measure, shipped a prompt that was 3453 characters against a 3200 cap, and only noticed when the CEO pasted the Easypanel log showing the runtime warning. The fix was one number ; the discipline failure was not measuring after the change. Exactly the "green build ≠ runtime correct" gap from the four-failed-fixes post.
• The DEBLO Agent rename, which I would have shipped silently if the CEO had not been explicit about it in chat. The positioning rule in CLAUDE.md is the structural defence ; reading the rule and pushing back is the discipline. I pushed back this time because the rule was visible in the conversation context. A future session where the rule has scrolled out of context would have shipped the rename. The cockpit + memory file system is the long-term mitigation.

The general shape of the build is therefore familiar from the prior post in this series. The agent executes well at composing the implementation, writing the boilerplate, drafting the documentation, running the audits. The strategic moves — what to build, what to refuse, what to defer, when to switch experiment shapes — come from the founder. The pair is the unit, not the agent.

Conclusion

The narrow story is : the three-person ZeroSuite ops team in Abidjan uses a single SvelteKit application called Conductor as their daily-driver internal workspace. The application has eleven sidebar surfaces, thirty-two AI tools, fifteen migrations, twenty tables, five external integrations (OpenRouter, fal.ai, Postmark, Hetzner S3, Sentry), and one login. It went from empty repository to active daily-driver in thirty-five sessions across four calendar days of focused development. It deliberately refuses to send, schedule, publish, or charge on the team's behalf — those are jobs for dedicated external tools — and it deliberately refuses to generalise its schema into blocks or workspaces or custom fields. It is opinionated about what it is and structural about what it is not.

The broader story is what the four-day build time, executed by one founder + one Claude Code instance, says about the economics of internal tooling at small-team scale in 2026. The build-versus-buy calculus that used to favour "buy" at every step — because internal tools were too expensive to build, and the SaaS subscriptions were affordable — has shifted at the four-day-build margin. Not because the SaaS subscriptions got more expensive, but because the build cost dropped by roughly an order of magnitude relative to what it used to be. A three-person team that would not previously have considered building their own internal workspace now can, for less time than it would take to onboard the same team onto a generalist project-management tool.

The corollary is not that small teams should always build. The corollary is that the build-versus-buy frontier has moved, and the new frontier passes through workflows like "internal multi-product launch ops" that used to live firmly on the buy side. Some workflows still belong on the buy side (transactional email, payment processing, ad management). Some workflows have moved to the build side (the rest of what Conductor does). The judgement that decides which is which is the founder's. The implementation cost of the build side is the AI co-pilot's.

Conductor is the proof, for one team at one scale, that the frontier moved. The thirty-five session logs, the fifteen migrations, the thirty-two tools, the eleven surfaces, the four-day build span — those are the evidence. The post is the report. The tool is in production, and the team uses it every day.

The next two posts in this series stay inside Conductor. Post 02 is the build log of a single four-session bug — the ComposerActionBar click bug — that taught both of us a sharper experiment shape under uncertainty, and is the better read for understanding how the pair makes decisions when the priors are weak. Post 03 walks the cockpit discipline itself : the cockpit/ directory layout, the session-log template, the post-implementation audit brief shape, the rules in CLAUDE.md that the agent reads at session start. The cockpit is the highest-leverage piece of meta-tooling in the ZeroSuite stack, and it is what makes the four-day-build claim survive context-window cycling. It deserves its own write-up after the bug story has set the stakes.

This piece was written collaboratively by Thales (CEO of ZeroSuite, building Déblo and the six other ZeroSuite products from Abidjan, Côte d'Ivoire) and Claude Opus 4.7 — Claude Code instance running on macOS, 1M context window. The application it describes is deployed at ops.zerosuite.dev via Easypanel against a Hetzner Postgres 17 instance. The eleven sidebar surfaces (Ask, Gallery, Notes, Resources, Overview, Tasks, Calendar, Launches, Assets, Distribution, Accounts) plus the team-chat widget plus the agent surface render daily for the three-person ops team. The thirty-five session logs covering the build are at session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md in the project repo (private). The thirty-two AI tools are declared in src/lib/server/ai/tools.ts. The fifteen migrations are at drizzle/. The brand-voice compliance ruleset is at docs/brand_voice_rules.yaml. The current cockpit roadmap names Phase 12 (global Cmd+K search extension) as the next ship ; J-13 to the Déblo public launch on 2026-06-15. Post 02 in this series covers the four-session ComposerActionBar bug and what it taught both of us about debugging discipline ; it is the better read for understanding how the pair makes decisions under uncertainty. Post 03 covers the cockpit discipline as the unit of repeatable build velocity.*