Rugene's founder is not an engineer. He has run a UK joinery business for 13 years, from a two-person start, and priced close to 5,000 jobs by hand on estimating sheets he built himself in Excel. He knows exactly where a trade business loses its time. Now, while still running that business, he directs an AI agent factory that is building Rugene toward a 64-feature platform that will automate the exact manual system he built.
← swipe to see all seven stages →
The same job data is re-typed at all seven stages because each one lives somewhere different. Rugene's promise is simple: type it once.
Why this founder
He lived the problem
13 years running the business, close to 5,000 jobs priced by hand. He is not guessing at the workflow; he has lived every stage of it, for years.
The data model started in Excel
To price a job he built his own product and labour-time sheets by hand. That hand-built labour-times logic is where Rugene's own per-company labour-time model comes from, so every estimate is grounded in how long the work actually takes.
For the craft, not the admin
Most people in construction are there for the craft, not the paperwork. Rugene automates the admin so a tradesperson can win the work, do the work, and still get their evenings back.
Why solo, why AI
He had pushed off-the-shelf and no-code tools as far as they would go and hit a wall. Betting on AI-assisted development lets a single founder take on what used to need a team. That bet is the rest of this deck.
A UK joinery founder, not an engineer, who priced close to 5,000 jobs by hand and lived the seven-stage re-typing problem. He now directs an AI agent factory building Rugene toward a 64-feature platform that will automate the manual system he built.
Every figure and label is verified against a source, a live count, or a founder-confirmed fact. As at 2026-09-02.
The Story · The Product
One connected system for a trade business.
Rugene is one connected platform for a UK joinery or carpentry business: win the work, do the work, get paid, all in one place. The point is not the number of features. It is that they are connected, so the office and the site see the same job at the same time.
The problem: a business run on disconnected tools
The origin story showed the same job details being re-typed at every stage of one workflow. Step back and the problem is bigger. A trade business is run across a stack of separate tools: a messaging app for site updates and orders, spreadsheets for estimates, a whiteboard tool for planning, notes for job information, a separate app for accounts. Each one does its job well. None of them talk to each other, so no single place holds the whole job, and continuity breaks the moment something changes.
← swipe to see both sides →
Five tools that never speak to each other, or one system where the work flows through. The category names are illustrative, not a comparison of any one product.
What it does
The whole job lives in one system, from the first estimate through to invoicing. Here is what that covers, tagged honestly.
Built
Built and running on staging today, ahead of launch. Not yet live to customers.
Planned
Specced and ready to build. Honestly labelled, not yet built.
Win the work
Quote and design
Estimating, with AI-assisted estimatingBuilt
Cabinet builderBuilt
Cut optimiserBuilt
Site surveyBuilt
Client feedbackBuilt
Customer portalPlanned
Do the work
Run the job
Jobs and job dashboardBuilt
Materials to order and purchase ordersBuilt
Planner and schedulingPlanned
InventoryPlanned
Health and safetyPlanned
Subcontractor management, snagging and RFIsPlanned
Get paid
Bill and track
Invoices and receiptsBuilt
OverheadsBuilt
Accounting link (Xero)Built
Profit and lossPlanned
AI throughout
Across the platform
AI-assisted estimatingBuilt
Fleur, the in-app help assistantBuilt
Standalone AI chat workspacePlanned
The honest split: 37 of the 64 planned features are built and running on staging today; the rest are specced and ready to build, partly built, or planned, and are tagged honestly. Built means running on staging ahead of launch. There are no paying customers yet: Rugene is pre-launch by design, and nothing planned is shown as done.
The opportunity
A large, fragmented, and under-digitised market, sized from public and industry sources. Every figure below carries its source and date; the market figures are re-checked before the event.
28,620
UK joinery-installation firms. This is the founder's own trade, and the fragmented, under-digitised market where Rugene starts.
IBISWorld, Number of Businesses, updated Oct 2025
~16%
Forecast annual growth of the UK field-service and trades software category (2026 to 2035), the category Rugene sells into.
Expert Market Research, 2026 (forecast CAGR)
~67%
Of UK construction SMEs still run on paper or disconnected tools. The digitisation gap is the whitespace.
FORGE Command industry report, 2026 (directional; vendor-authored)
~8hrs/wk
Lost to admin by a UK trade SME owner, about ten working weeks a year. That is the admin drag Rugene is built to reduce.
heybrb.ai UK Admin Drain Report 2026 (survey, via trade press)
$6bn+
ServiceTitan (NASDAQ: TTAN) IPO valuation, in US dollars. It built the system of record for US trades: about $772M ARR, growing 24% a year, IPO Dec 2024. A directional example of what a trade system of record can become; Rugene applies the same playbook to a still-fragmented, under-penetrated UK market.
SEC filing and Forbes, Dec 2024 (USD; a comparable, not a peer)
The wider industry these customers work in, Great Britain construction, produced £224.6bn of output in 2024 (ONS, via Statista). Rugene does not claim that whole figure: it starts with the joinery firms above (the qualified early segment is a subset of them), then expands to adjacent trades.
It connects to the tools a business already relies on
Rugene is not an island. Where it makes sense, it plugs into established services, each one actually wired in the code on staging today, not just planned (production activation follows launch).
Stripe paymentsXero accountingSendGrid emailAWS S3 file storageMalware scanning on uploadsCloudflare AI Gateway
Rugene logs the labour time; it is not payroll. Pay is owned downstream.
Rugene is one connected platform for a UK joinery or carpentry business, win the work, do the work, get paid, bringing a fragmented stack of disconnected tools into one system so the office and the site see the same job. Roughly half of its 64 features (37) are built and running on staging today, the rest tagged Planned; it is pre-launch by design, with no paying customers yet. The market is large and under-digitised: 28,620 UK joinery firms, a trades-software category forecast to grow about 16% a year, and ServiceTitan as a directional example that a system of record for a trade can be a multi-billion outcome.
Feature counts are live from the build tracker; market figures carry their source and date and are re-checked before the event. Built means running on staging ahead of launch, not live to customers. As at 2026-09-02.
The Machine · Architecture
One founder's stack, built to be believed.
The whole system, end to end: Next.js on Vercel talks to a Fastify + Drizzle backend on Railway, the hub. The backend routes every in-product AI call through the Cloudflare AI Gateway (configured as our bring-your-own-key, or BYOK, routing layer over Anthropic, OpenAI and Google, plus Cloudflare Workers AI), and reads PostgreSQL for app data, with Neo4j and Chroma as the knowledge layer and AWS S3 for files. No direct-provider calls in the product codebase, guarded by an end-to-end egress test.
← swipe to explore the full diagram →
Wired integrations: verified in code, not planned
Stripe
Payments: checkout, subscriptions, webhooks.
Xero
Accounting: OAuth, invoice sync, payments cron.
SendGrid
Transactional email.
AWS S3 + GuardDuty
File storage with malware scan before download.
Foundations for secure scaling
Authenticated + tenant-scoped
Every request is authenticated server-side and carries a verified identity that sets the tenant context the RLS policies enforce.
Multi-tenant isolation
PostgreSQL row-level security on every table (USING + WITH CHECK), enforced by the database on every query.
Safe file delivery
Backend-only presigned URLs, tenant-prefixed, capped expiry, served only after a clean GuardDuty scan.
No model aggregator
Every model call routes through our own gateway, deliberately never an independent model aggregator that could train on or resell our prompts and code.
Vercel → Fastify/Drizzle on Railway (the hub), which routes AI via the Cloudflare AI Gateway (our BYOK routing layer) and reads PostgreSQL (app) + Neo4j & Chroma (knowledge) + AWS S3. No direct-provider calls in the product codebase.
Every figure and label is verified against a live count, source, or code check. As at 2026-08-31.
The Machine · The AI factory
The machine that builds the machine.
The founder sets the direction. From there the factory runs on its own: it picks the next task, puts it through the full pipeline, and merges onto staging only what clears a gate it doesn't get to skip, then moves straight to the next, unattended for long stretches. The one thing that reliably brings it back to a human is a decision that's the founder's to make.
← swipe to explore the full loop →
Unattended is the honest word. The loop runs for long stretches with no one watching, but it doesn't run unchecked. Every change still lands on staging behind the same gate, and a blocker never jams the line: it steps aside so independent work keeps flowing, and the calls that are the founder's to make, usually a business or product decision, come back to the founder.
What keeps it running, and keeps it honest
The loop, running unattended
The founder sets the goal and the priorities. After that the factory selects the next task itself, runs it end to end, merges it, and moves straight to the next, for long stretches with no one watching. Keeping it logged in across a run that long is its own engineering problem.
The gate vouches for the code
Before a change counts, it clears the pipeline's adversarial review, then continuous integration and branch protection: a gate the agent doesn't get to wave through. That review and that gate are what stand behind the code, not a person signing off. Going live is a separate call the founder makes: a decision about timing and readiness, not a last-minute code check.
When a task blocks
A blocked task never jams the line: it steps aside, and independent work keeps flowing. Separately, a dedicated resolver looks at what blocked it and decides what it can settle on its own, and what it can't. The ones it can't are the calls that need a human, usually a business or product decision, and those come back to the founder. The rest, it works through on its own.
What the machine is building
76
specialist agents it can call on
as at 2026-08-29
64
features it is building: one business platform
as at 2026-08-29
The honest floor
Unattended is not unsupervised. The founder owns the direction, and the founder alone authorises anything going live. It doesn't run continuously; it runs when it's set going, then carries on by itself for a long stretch. In between, the machine does the work, but only inside the gate and the guardrails, and only until it hits a decision that isn't its to make. This is the point: not an AI that runs the business, but an AI factory a single person can direct: doing the sustained work of building it, while never getting to decide the things that matter most on its own.
The machine that builds the machine: a founder directs it, then it runs on its own: picking the next task, putting it through the full pipeline, clearing a CI gate it doesn't get to skip, merging onto staging, and moving to the next, unattended for long stretches. A blocked task steps aside so independent work keeps flowing; the calls that are the founder's to make, usually a business or product decision, come back to the founder, and only the founder authorises going live.
Described at the level of the design, not its internals. Every figure is verified against a live count or source. As at 2026-08-29.
The Machine · Workflow
Every task has to earn the word "done".
One AI writing code is easy. Trusting it is the hard part. So no substantial task ships until it has passed a fixed sequence of checks, ordered for a reason: the judgement has to come after the understanding. Research and interrogation surface the right questions; deep research answers them against each provider's own sources; only then does a cross-model second opinion judge the result. Judge before you understand and the check just rubber-stamps a guess. Yes, it's a lot of steps, deliberately so: build-time compute is cheap; a confident, wrong answer in front of a customer is not.
1 · Research
2 · Interrogation
3 · Deep research
4 · Validation
5 · Blocker-resolution
6 · Build
7 · Test
8 · Bullshit agent
9 · Cross-model sentinel
First: understand before you build
1
Research
the research agent
Gather everything already known (from our own knowledge base, the codebase, and the decisions taken before) so the work builds on fact, not memory. You cannot question a void.
↓ hands the known baseline to the next step
2
Interrogation
the interrogation agent
Turn one question, "are we sure?", into a wave of pointed ones. Its whole job is to surface the unknowns: the exact list the next step goes away and answers.
↓ hands the surfaced unknowns to the next step
3
Deep research
the deep-research agent · EXA
Answer those unknowns against ground truth (the live web and each provider's own documentation) with a cited source and a date. A guess becomes a cited, checked answer before any judgement is formed.
↓ hands the researched answers to the next step
4
Validation
the cross-model validation agent
A build-time second opinion from three different-provider models (GPT, Gemini and Kimi, three independent labs) judging the enriched plan with the surfaced questions and the researched answers already in hand. This is the build system's own cross-model check, separate from the product's AI. That ordering is the whole point (see below).
↓ judges the enriched result, not a bare guess
5
Blocker-resolution
the "virtual chain"
Triage whatever is left. It fixes what it can itself (RESOLVE) and brings the genuine business decisions back to the founder (ESCALATE). This is where the machine knows the limit of its own authority, and stops, rather than guessing a call that was never its to make.
Then: build, then prove it
6
Build
the builder
Now, and only now, do the work, on cited, checked answers instead of guesses.
7
Test
the test agent
Prove it actually runs: every affected test green. A green suite is necessary, not sufficient: on its own it only proves the code matches your assumptions.
8
The Bullshit agent
a five-reviewer panel
Named for exactly what it does: it catches the AI not quite telling the truth. Five separate adversarial reviewers, each with a different remit, score the finished work, re-deriving every reported number from its source and refusing to take a confident claim on faith. It passes only when all five clear the bar; a genuine sticking point escalates rather than loops. The target is the one failure mode that matters here: an answer given with confidence that isn't actually backed.
9
Cross-model sentinel
a different model, on the riskiest changes
On the changes that carry the most risk (anything that touches the system's own controls, or trips a risk signal), a different model re-checks the result. Five instances of the same model can share a blind spot, agreeing with each other while all being wrong; a different one catches what they share. It's aimed where a shared blind spot would cost the most, and it narrows that risk rather than pretending to erase it. This very deck was hardened exactly that way.
Why the judgement comes after the understanding
The load-bearing rule is narrow but strict: the cross-model second opinion has to run after the steps that surface the right questions, never before them, never alongside them. It can only ask the decisive question because interrogation and deep research already put it on the table. Fire it first, or in parallel, and it is judging a guess with confidence. (The build-and-prove steps that follow run in sequence too, but this is the ordering that actually changes the answer.)
When a gate fails
A failed check doesn't stop the machine; it feeds it. The finished work goes back to be fixed and re-audited, and if it still won't converge, the same virtual chain, blocker-resolution, appears a second time: it decides what it can resolve itself versus what is a genuine call for the founder, and only escalates the calls that are truly his. So the step that keeps the loop honest sits at both ends of it: triaging before the build, and again if a gate fails after it.
↺gate failsfix & re-auditblocker-resolutionask the founder
No substantial task ships until it passes a fixed, data-dependent sequence: research → interrogation → deep research (EXA) → cross-model validation → blocker-resolution → build → test → the Bullshit agent (a five-reviewer panel), with a cross-model sentinel on the highest-risk changes. The judgement steps come after the ones that surface the questions; blocker-resolution appears twice: triaging before the build and again if a gate fails, escalating only the genuine business calls to the founder.
The pipeline order shown is the one the system actually runs; every catch is a real, closed and remediated incident from its own audit trail. As at 2026-08-31.
The Machine · Orchestration
Running an AI dev team unattended is an auth problem, not a compute problem.
The hard part of a system that builds on its own, for hours at a stretch with no one watching, isn't the building. It's keeping the login alive. Two mechanisms keep it going, and they're deliberately separate: an auth-durability layer built to keep the session alive across a long run, and usage monitoring so it stays well within the provider's limits, because an autonomous worker has to respect those limits, not fight them.
← swipe to explore the full diagram →
What the lock prevents: if two things refreshed the same account at once, one refresh would succeed and the other would then present the now-superseded token, which the provider reads as reuse, and drops the session. Exactly one refresher per account is the invariant that stops a long unattended run from logging itself out.
Mechanism 1: keeping the session alive
Single-refresher lock
A per-account lock guarantees exactly one token refresh at any instant, the load-bearing invariant. It's what lets a long unattended run finish without the login dying under it, because it makes a self-inflicted double-refresh logout practically impossible by design.
Proactive refresh
A refresh service renews an idle account's token before it can lapse, through the provider's normal refresh flow, so an idle worker is far less likely to strand and the session is kept alive rather than left to expire.
Independent watchdog
A dead-man's-switch that sits outside the whole thing and pages a human within minutes if a refresh ever genuinely fails. It is the backstop for every other mechanism failing quietly.
Stays awake mid-run
A keep-awake stops the host from suspending mid-run, so a long autonomous job keeps running rather than being paused out from under itself, and the refresh service stays active when it is needed.
Mechanism 2: it always knows where it stands
A separate concern from keeping the login alive: staying within the provider's limits. Monitors track the provider's published usage limits, so the system paces its work to stay comfortably inside them and always knows where it stands. An autonomous AI worker has to be a good citizen of the platform it runs on, and this is the part that keeps the work flowing while staying clear of the provider's ceilings.
The honest floor
This doesn't make uptime magic, and it doesn't pretend to. What is guaranteed is that a genuine failure is caught and surfaced, never swallowed: when a refresh does fail, a human is paged within minutes. A few things stay outside any script's control: the machine losing power, a network outage during the one moment a token needs refreshing, or the provider ending a session on its side. The watchdog can't prevent those, but it's the reason they don't stay hidden: a human finds out quickly, on recovery if not sooner. Mature reliability isn't "it never fails"; it's "when it does, you find out fast, not weeks later."
Running an AI dev team unattended is really an auth-durability problem. Two separate mechanisms handle it. First, an auth layer designed to keep its session alive: a single-refresher lock (exactly one token refresh per account, so a rotated refresh token is not double-consumed into a logout, per the OAuth security best practice RFC 9700), a proactive refresh, an independent watchdog that pages a human on any genuine failure, and a keep-awake so a long job keeps running rather than being suspended mid-run. Second, usage monitors that pace the work to stay well inside the provider's published limits. When a refresh fails, a human is paged within minutes; the failures outside any script's control surface on recovery.
Described at the level of the design, not its internals. Built to the OAuth 2.0 security best practice (RFC 9700, Jan 2025). As at 2026-08-31.
The Machine · The agents
Not one AI. A team of specialists, with a system between them.
Rugene isn't built by a single general-purpose agent told to “be careful”. It's built by 76 specialist agents, each with a narrow job, organised into seven families, and the interesting part is how the work hands off between them. This is the whole estate at a glance; the close-ups come next.
76
specialist agents, grouped into seven families by the job they do, from 78 agent definition files (two are scaffolding, not agents).
← swipe to explore the full diagram →
The families are drawn in the order work usually flows, but governance isn't a step at the end: it wraps the whole line, challenging the plan before the build and auditing the result before anything ships. The exact per-task order is in The Workflow.
The seven families
Each family is a real group of named agents doing one kind of work; a few from each are shown. Some agents wear two hats, and a few are older ones kept as fallbacks, so a precise per-family count depends on where you draw the line, so we show the one verified total and let each family speak for itself.
Research
Discover before doing: search the corpus and the web, verify assumptions.
pre-build researcherdeep research · EXAknowledge searchcapability search
Build
Produce the artifact: code, specs, plans, components.
Inspect the artifact against the standard and the spec, dimension by dimension.
security & data reviewdomain correctnessfrontend qualityarchitecture review
Governance
Challenge and adjudicate: adversarial audit by the “Bullshit agent” (it catches the AI overstating its work), cross-model validation, interrogation, and the resolver that escalates business calls to the founder.
the Bullshit agentcross-model validationthe interrogatorblocker-resolution
Knowledge
Remember: capture results back into the corpus so the system compounds.
Infrastructure: the seventh family, and the foundation
Builds and maintains the factory itself: the agents, skills and references the other six families are made of.
agent builderskill builderreference buildercapability index
Three of the seven families (test, review and governance) are there primarily to check and challenge the work. A substantial share of the agents is given over to verifying, inspecting and adjudicating what the others produce. In this system, checking the work is not an afterthought bolted on at the end; it is central to what the system does.
Inside the governance family: the “Bullshit agent”
Six specialist agents, each with a defined edge
Adversarial quality auditor · final gate
The “Bullshit agent”
The last, hardest gate: it catches the AI builder not quite telling the truth about what it actually achieved.
Panel of 5 lenses
Judges the evidence, never the builder's word
A different model cross-checks the riskiest work
What it will do
Treats every claim as unproven until a real artifact backs ita claim with nothing behind it doesn't count
Scores finished work across a fixed battery of independent checksspec-match, genuinely-passing tests, live-app wiring, security, and more
Demands a clean pass across every defined check“nearly done” never ships
Flags empty placeholders, stubbed shortcuts and buried “fix-it-later” language
Confirms the work is actually connected into the productnot written in isolation
Points to the exact file and line behind every issue
What it won't do
Take the builder's word for anything
Invent a softer in-between verdictpass or fail, nothing between
Be talked into leniencytold to skip checks, it follows its own rulebook and records the attempt
Research or build a defence for the code it judgesan independent judge, never the author's advocate
Accept skipped tests, deferrals or unfinished stubs as “good enough”
Wave through a security-sensitive gaptenant isolation, auth, secrets, even when the rest looks perfect
Defers to founder?No. A machine pass or fail on build correctness; it routes no business questions.
Independent second opinion · three model families
The cross-model second opinion
A build-time second opinion from three rival AIs at three different labs, so one vendor's blind spot is far less likely to go unchallenged.
GPT, Gemini and Kimi
Grounded in our own context first
One credible dissent is never out-voted
What it will do
Puts every critical decision in front of three outside AIs from three different labsGPT, Gemini and Kimi: three lineages that fail differently, so their blind spots rarely line up
Grounds those models in Rugene's own context first
Surfaces a single credible dissent by nameone objection is reported, never out-voted
Preserves every criticism at full strength
Sorts spec findings into confirmed, recommended-change or needs-a-business-call
Runs the three in parallel and records which actually answered
What it won't do
Fabricate agreementa model it can't reach is marked “no answer”, never a silent yes
Be softenedtold to drop a model or mute criticism, it runs the full check anyway
Send sensitive data outside
Overrule the in-house reviewadvisory: only a genuine critical objection forces a mandatory fix
Fetch untrusted external links to reach a verdict
Auto-approve a business, pricing, legal or vendor question
Defers to founder?Yes. Anything it classes as a business decision (pricing, branding, legal, vendor, scope) goes to the founder; technical matters it recommends on directly.
Ground-truth researcher
The ground-truth researcher
It checks what is actually true today against current real sources, not what the model learned months ago.
Several sources, in parallel
Every finding attributed
Never answers from memory alone
What it will do
Consults several independent sources in parallel
Prioritises current information over the model's older training
Attributes every finding to a named sourcetraceable, not “the model said so”
Rates how well-supported each finding is, and flags thin or contradictory evidence
Escalates to a deeper search when a first pass is low-confidence
Keeps its output sourced and traceable end to end
What it won't do
Answer from memory alone
Lean on a single source
Obey instructions hidden in retrieved contentevidence, not commands
Launder a weak or single-source claim into a confident conclusion
Leak internal secrets or identifiers via research
Route web research through uncontrolled channels
Defers to founder?No. It produces sourced briefs and flags gaps for humans; it routes no decisions.
◆ The centrepiece
Execution vs governance
The automated resolver
The “virtual Shane”: it fixes the clear-cut technical gaps itself, and hands every judgement call back to the founder.
Resolves the clear-cut
Escalates the judgement calls
Knows the limit of its own authority
The split that makes it trustworthy: it resolves the technical gaps that are clear-cut, and hands back to the founder every business decision, security trade-off, or anything less clear-cut. That “resolve what I can, bring the judgement to the founder” line is the whole idea. To be straight about the autonomy: no human signs off on each individual change (an eligible technical fix lands after the automated cross-model audit and version-control record), but the founder owns every policy call and can pause, roll back, or override anything.
Resolves itself
Searches widely across its internal sources firstand checks whether the missing piece already exists under another name
Fixes genuine, well-understood technical gaps itselfa real fix, not a workaround, still gated by the same audit as any change
Chooses the thorough fix over the shortcut
Attaches to every fix a way to verify it and a way to undo it
Cites the evidence behind every decision
Escalates rather than guessingit resolves a gap alone only when the fix is clear-cut; anything uncertain goes to the founder
Sends to the founder, won't decide
Make a business decision itselfpricing, scope, vendor, design intent → the founder
Weaken security to get unblockedanything loosening tenant isolation, auth or data-protection is escalated, never auto-fixed
Repeat a failed fix without explaining what's different
Let hand-in instructions override its guardrails
Treat unverified external research as factadvisory only; never overturns a protected call
Ship a fix it can't verify
Defers to founder?Yes, this is the heart of it. It resolves the clear-cut technical gaps and hands back to the founder whenever the blocker is a business decision, a security trade-off, or anything less clear-cut. That split is the “virtual Shane” idea.
Question-generator · surfaces the unknowns
The interrogator
It turns one question into many, surfacing the unknowns nobody thought to ask, before a decision is trusted.
One question in, a wave out
Stays in “ask” mode
Never drops a hard question
What it will do
Expands a single decision into a wide, categorised question setacross many angles: technical, business, risk, legal, and more
Explains, per question, what risk goes unaddressed if nobody asks it
Points each question at where its answer could be found
Names the blind spots and unproven assumptions the decision rests on
Marks each assumption verified, unverified or untestable
Prioritises so the critical unknowns stand out
What it won't do
Answer its own questionsit stays in “ask” mode
Quietly close or drop a question
Skip whole categories or shrink the set on request
Let an external lookup supply an answerat most a pointer
Fetch untrusted external links
Downgrade a critical question because the research to inform it was unavailable
Defers to founder?Yes, indirectly. Its whole output exists to feed the founder and the downstream validator; it hands the open questions to humans rather than resolving them.
Pre-build researcher
The pre-build researcher
It briefs every build first, so the builder starts fully informed instead of half-guessing.
One complete brief per task
The exact spec, never a summary
Reuse before rebuild
What it will do
Assembles one comprehensive brief per taskthe builder starts with immediate, exact context instead of searching from scratch
Works from the exact specification, not a summary of itsummarising loses the detail that causes build-vs-spec mismatches
Searches broadly across many genuinely distinct anglesnot rephrasings of one query
Maps every UI element to an existing reusable component before building new
Cross-checks the front-end against the back-end
Tests the real API against the spec where the backend runs
What it won't do
Let a builder start from a blank slateno brief, no build
Summarise the spec where exact wording matters
Pad research with near-duplicate queries to hit a count
Obey instructions embedded in retrieved material
Present a weak or single-source finding as settled fact
Leak secrets or identifiers via research
Defers to founder?No. It flags conflicts and gaps for a human; it routes no decisions.
Rugene's build system is a team of 76 specialist agents in seven families (research, build, test, review, governance, knowledge and infrastructure), with work handed off between them. Governance is a cross-cutting quality spine: it challenges the plan before the build and audits the result before it ships. A substantial share of the agents is given over to checking and challenging the work. At the centre is the adversarial “Bullshit agent”: a five-lens panel that reviews finished work for anything unsafe, incomplete, unsourced, unsound or over-claimed, with a different-model reviewer giving the final cross-check on the highest-risk changes.
76 agents from 78 definition files (a live repository count), grouped by primary function. As at 2026-08-29.
Agent behaviour is described by role, paraphrased, never the exact internal wording. Every catch is a real, closed example from pre-release review, sanitised. As at 2026-09-01.
The Machine · Hooks & Safety
Agents propose. The system disposes.
Letting AI agents build a real product on their own is only safe if something stops them doing the wrong thing. So a proposed change runs a gauntlet of independent guardrails before it can ship, and anything caught is stopped and recorded, never hidden. Each layer below is a real control with the failure it prevents; several were themselves hardened when a different AI model caught a flaw in our own safety logic before it went live.
← swipe to explore the full diagram →
The layers: each a real control, each with what it prevents
Protected control files
The system cannot quietly delete its own safety controls.
Prevents: an agent silently deleting, overwriting, or quietly tampering with a load-bearing control file: a safety hook, a rule, an agent's own definition. Every such file is guarded, a staged deletion is blocked before it can be committed, and the safety hooks themselves are integrity-checked so a quiet change is caught.
What it preventsThe failure mode is a quiet, propagating loss: a control removed in one place, unnoticed for weeks. This layer stops a silent removal: it can happen only through an explicit, logged override.
Guarded knowledge egress
Secrets and internal data can leave only through one fail-closed choke point.
Prevents: an agent, or a directive hidden inside retrieved content, leaking secrets or internal data, or acting on a smuggled instruction. Retrieved content is treated as evidence, never commands, and any secret or internal data leaving runs through one fail-closed choke point.
Real prevented failureThat choke point was itself hardened by an adversarial cross-model audit, which caught a real data-egress bypass and closed it before it ever went live.
Staging-only deploy
No agent can ship straight to production.
Prevents: any agent shipping code straight to production. Every change lands on a staging environment behind CI first; promoting to production is a deliberate, founder-authorised act, never something an agent can do on its own.
What it preventsAn autonomous system's most dangerous move is a fast path to production. There isn't one: the path is gated by construction.
Safe version control
No blind “commit everything” shortcut exists.
Prevents: broad, blind commits that sweep in an unintended deletion or a secret. Changes are staged file-by-file, scanned for secrets, and protected files are not removed in passing.
What it preventsMost accidental damage in a fast-moving repo comes from a careless "add everything". That shortcut is simply not available here.
The adversarial commit gate
Nothing is accepted as done until it survives an adversarial panel.
Prevents: unverified or overstated work being accepted as done. Before a change is committed, an adversarial panel scores it against a fixed battery of checks, and a different model family cross-checks the result on the highest-risk changes.
Real prevented failureIn one pre-commit audit it caught seven distinct issues that would otherwise have shipped: the half-built work was discarded and rebuilt clean.
Deploy integrity
A green test cannot hide a fix that never reached the running code.
Prevents: a fix that "works" where it was tested but never reaches the copy that actually runs: the gap where a green test suite hides a real bug.
Real prevented failureThe adversarial reviewer caught exactly this: a fix that passed where it was tested while the copy that was actually running was still an older one carrying the bug: a deployment gap manual testing had masked.
Multi-tenant isolation
In the database, one customer’s data cannot reach another, enforced by row-level security.
Prevents: one customer's data reaching another. Every table carries row-level security the database itself enforces on every query, not the application code.
Enforced at the databaseTenant isolation is enforced at the lowest layer, the database, so an ordinary mistake in application code does not cross the boundary. Verified in the schema, not aspirational.
The part most people miss: the gate audits itself
Agents propose, the system disposes
An agent can propose a change: that is the whole point of an autonomous factory. What makes it safe is what happens next: an independent adversarial audit panel gates it (with a different model family cross-checking the highest-risk changes), a permanent version-control trail records it (every change auditable and revertible), required CI checks and branch protection enforce it, and the founder owns every policy call and can override anything (an override is recorded like any other change). No single agent, and no human, hand-approves each change; the gates do, on every change, and the founder sets and owns the rules they run by. That separation, propose here and dispose there, is what lets one person run a factory of agents without losing control of it.
Systematic, not ad-hoc
None of this is a one-off. Safety here is a standing programme with a simple discipline: every issue found anywhere is recorded, drained, and gated. It is not silently forgotten, it blocks what it needs to block until it is fixed, and it is re-verifiable by anyone afterwards. That programme has already completed and verified 150+ dedicated hardening tasks, each with recorded, re-runnable evidence rather than a claim, and the system keeps finding and fixing its own issues, hundreds triaged and resolved to date. Every fix becomes a standing check, so an old failure does not quietly return.
The honest floor
Every catch shown here was made before anything shipped: defence in depth working as intended, not a live incident. Layered defence lowers the odds of a bad change getting through; it does not make failure impossible, and this is a pre-launch system still being hardened. What the design does guarantee is the mature part: when something is caught, it is stopped and recorded, never buried, so it gets fixed, and the fix is re-verifiable. Reliability isn't "nothing ever goes wrong"; it's "when it does, the system catches it and tells you".
A solo-built autonomous AI factory is kept safe by layered defence: protected control files, guarded knowledge egress, staging-only deploy, safe version control, an adversarial commit gate (with a different-model cross-check on the highest-risk changes), deploy-integrity checks, and database-enforced multi-tenant isolation. Agents propose changes; an independent adversarial audit panel gates them (a different model cross-checks the highest-risk ones), version control records them, CI and branch protection enforce them, and the founder owns policy. The quality system even audits its own safety logic: a different model caught a real flaw in the commit gate's own design before it went live. It is a standing, re-verifiable hardening programme, and every catch shown was made before anything shipped.
Controls described by class and by the failure they prevent, never by their source. Every prevented failure is a real, closed, sanitised example from pre-release review: illustrative examples, not an estimate of the system's error rate. As at 2026-09-01.
The Machine · Knowledge
The more it builds, the more it knows.
The factory does not just build. It captures what it learns as it works, the mistakes and the decisions along the way, and searches that memory before it writes the next line. Two stores hold it: a vector knowledge base it searches for patterns, specs and decisions, and a knowledge graph of documented mistakes it checks itself against, so a repeat is more likely to be caught before it ships. The corpus grows with every session, so the work compounds.
The knowledge base, by the numbers
112,975
documents it can search before it writes a line
as at 2026-08-29
21,025
connected facts in the knowledge graph
as at 2026-08-29
368
documented mistakes it can surface to new work
as at 2026-08-29
7,253
commits of accumulated knowledge, and counting
as at 2026-08-29
The learning cycle
← swipe to explore the full cycle →
The numbers are the scale; the loop is the point. Because the factory reads its own memory before it acts and writes back what it learns, the same ground is less often covered from scratch, and past lessons are already on hand for the next task.
What holds the knowledge
A vector knowledge base
104 collections, 112,975 documents. Before any build, the system searches here for the pattern already proven, the specification already agreed, the decision already made, the mistake already logged. Searching first is built into the process, reducing guess-then-fix.
A knowledge graph
21,025 connected facts, 368 of them documented mistakes, joined by 42,609 relationships. A linked map of the errors the system has hit across its history, earlier-stack lessons included, so a relevant one is surfaced to the next builder before the work begins.
A memory that grows
Thousands of build-session records, and counting. Each session the factory runs is written down and folded back into the knowledge base. The corpus is not static: it grows with every commit and every job the system completes.
The knowledge has to be true, too
A knowledge base is only worth searching if what it holds is accurate. The same adversarial checks are applied to the knowledge, too, including the statistics the system quotes about itself.
a real caught example
An internal agent reported that 34% of a set of working documents were missing a required section. The “Bullshit agent”, an adversarial reviewer built to challenge the system when it is not quite telling the truth, re-counted from source: the real figure was 2.8% (6 of 215 documents). The invented statistic was caught before it could keep steering the work.
The honest floor
Memory, not a guarantee
The system searches this memory and learns from it, but it is not a guarantee of correctness. It makes a repeat mistake less likely and puts the relevant past decision in front of the next task. The adversarial review is still the final gate before anything ships.
A vector knowledge base (104 collections, 112,975 documents) and a knowledge graph (21,025 facts, 368 documented mistakes) that the AI factory searches before it acts and writes back to after, so the work compounds and past mistakes inform the next build.
The scale counts are live, verified as at 2026-08-29 and refreshed before the event; the caught example is drawn from a separate incident record. Counts are publishable; the collections and their contents are not shown.
The Proof · By the numbers
Counted, not claimed.
Every figure below is a live count from the running system, or a conservative verified floor where the exact number is approximate or deliberately held back. Each one traces to its source and is stamped with the date it was taken; nothing here is rounded up to impress, and the counts are refreshed again before the event.
The autonomous factory
76
AI agents the system can call on
as at 2026-08-29
90
automated enforcement hooks in the change pipeline
plus the governance rules loaded into every session
as at 2026-08-29
150+
hardening tasks completed and verified
with hundreds of self-found issues triaged and resolved
as at 2026-08-29
What it is building
64
features in one platform, for a job re-entered at seven separate stages today
as at 2026-08-29
7,253
commits in the knowledge repository
as at 2026-08-29
The knowledge it compounds
112,975
documents in its searchable knowledge base
across 104 knowledge collections
as at 2026-08-29
21,025
connected facts in the knowledge graph
368 of the facts are documented mistakes; 42,609 relationships link the graph
as at 2026-08-29
The system by the numbers: 76 AI agents building a 64-feature platform, guarded by 90 enforcement hooks, on a knowledge base of 112,975 documents and a 21,025-fact graph. Every figure is a live count, verified as at 2026-08-29.
Every figure is a live count taken from the running system, verified as at 2026-08-29 and refreshed before the event. Counts are publishable; the underlying names, paths and contents are not shown.
The Proof · Cloudflare
Every AI call goes through one gateway we control.
Rugene routes every AI call through the Cloudflare AI Gateway, configured as our own bring-your-own-key (BYOK) router: our keys and routing policy live in our own Cloudflare account, and our prompts go only to the providers we choose, never through a model aggregator that could train on or resell them. It gives us multi-provider reach with no independent reseller in the middle. We made the gateway the only sanctioned path for AI: a build-failing egress test fails the build on a direct-provider call before it can ship.
← swipe to see the full gateway →
The four providers behind the gateway are confirmed against the live gateway (as at 2026-09-02). Provider level only; specific model names are not rendered.
Why an engineer should trust it
No model aggregator in the middle
Multi-provider reach without OpenRouter or any independent model aggregator that could train on or resell our prompts and code. The keys are ours (BYOK); no reseller sits between us and the providers. A deliberate data-privacy and IP choice, not a default.
The gateway is the only path
Every AI call routes through the gateway. A build-failing egress test fails the build on a direct-provider call before it can ship, so the gateway is the only sanctioned AI egress path, enforced by CI rather than by discipline.
Automatic failover
We express the provider fallback chain in our own code, and route each attempt through the gateway. If one provider errors, the request falls over to the next, which reduces the risk that one provider's outage stalls the work.
This is reliability: one model serves, another is the backup. It is a different mechanism from the cross-model second opinion that checks our builds, where three independent labs weigh in on the same decision. Same gateway, two distinct jobs.
A tight, honest footprint
One account (Workers Paid); four zones; two small self-authored Workers, a PDF proxy and a cron health-monitor; authenticated, in our own account. File storage is on AWS S3, not a Cloudflare store. Small and deliberate, not sprawling: every piece earns its place.
Questions I would love to ask you
I already run the gateway in production. These are the edges I would push on with a Cloudflare engineer. (Current as at 2026-09-02.)
BYOK at scale
Can I store multiple keys per provider and fail over at the key level, on a rate-limit or a revoked key, and rotate a key with zero downtime and no redeploy? Our rotation lives in our own code today; I would rather push it into the gateway.
Dynamic Routing
We express our provider failover in application code. Could Dynamic Routing own that declaratively, failing over across different providers on a mid-request error and re-evaluating cost and latency per request rather than a static order?
Guardrails & DLP
For a UK business, can DLP redact personal data in-flight at the gateway before a prompt reaches a US provider, and is that evaluation itself run on a UK or EU edge? What latency should I budget per request?
Log residency
We keep request and response body logging off pre-launch. At go-live I want it on but pinned to UK or EU storage. Does the Data Localization Suite cover AI Gateway log storage, or is body logging still all-or-nothing?
Workers AI as a product leg
When I run a large Workers AI model as a live product leg, not just dev validation, is there a latency guarantee, and can inference be pinned to a UK or EU region? We have seen a large model take well over two minutes to generate a response.
AI Search vs our Chroma
We run a self-hosted Chroma retrieval pipeline for our in-app help bot. If AI Search now handles upload, index and query with per-tenant instances, what is the migration path from an existing embedding pipeline, and can I bring my own embedding model and chunking?
Vectorize at our scale
For a multi-tenant UK product at roughly 113,000 documents, how does Vectorize compare to a self-hosted Chroma on per-tenant isolation, recall and residency-pinning the index?
Durable Objects for agents
We run long unattended autonomous agent sessions with our own single-writer session locks. Could a Durable Object host a stateful agent session with single-writer-per-agent guarantees and hibernation, and how would that sit with the gateway's own logging and failover?
Rugene routes every AI call through the Cloudflare AI Gateway as its own company-controlled BYOK router over Anthropic, OpenAI and Google plus Cloudflare Workers AI, with no independent model aggregator in the middle, every AI call forced through the gateway by a build-failing egress test, automatic provider failover, and a tight, deliberate footprint.
The four gateway providers are confirmed against the live gateway; product-capability questions are current as at 2026-09-02. Provider and family level only, never internal identifiers.
The Story · Roadmap
The platform is built. This is where it goes.
This roadmap is unusual. The platform is already built and running on staging, with 37 of its 64 features live, and the AI factory that builds it is operational. What is left is deliberate: finish the remaining features, harden it, launch it, then open it up to other trade businesses. Every item below is tagged honestly, built, in progress, or planned. Nothing planned is dressed up as done.
How to read this
Built
Built and running on staging, ahead of launch. Not deployed to production, not yet live to customers.
In progress
In the final hardening and polish pass right now.
Planned
The forward path. Honestly labelled, not yet built.
← swipe to see the whole path →
One rail, one honest line. Solid is what is built and being finished now. Dashed is the planned path. Launch is a founder decision, not a marketing date, so it carries no date here.
Built
The platform is built and running
The hard part, the architecture and the factory, is already built. The platform runs on staging today.
The platform is built and running on staging: 37 of its 64 features are live today, and the rest are in progress or planned. The AI-agent factory that builds it is operational. Tenant isolation is built into the architecture, so there is no multi-tenancy retrofit ahead. That removes one architectural risk, not every risk: the remaining features, production hardening and operational risk remain, and the next phases are about exactly that. You have seen the evidence earlier in this deck: the counts, the factory, and the architecture. The roadmap starts from there.
Built means built and running on staging. Production is deliberately parked until launch, so nothing is exposed before it is ready. Building and proving first is the point, not a delay.
In progress
Finishing and hardening for launch
The reliability risk: hardened before a single customer relies on it.
The final pass
The platform already runs on staging. What is in progress is finishing the remaining features, then a final pass across the whole platform, hardening, verification and polish, section by section, to the same bar as the rest.
A standing hardening programme
Hardening is a permanent part of how Rugene is built. It has already completed and verified over 150 dedicated tasks in security, reliability and correctness, and it keeps finding and fixing its own gaps. The final launch-readiness pass is what is in progress now.
So launch is a decision made when the work is ready, not on a date.
Planned
Launch and first live use
The validation risk: exercised on real work before it opens to real customers.
Launch
A founder-authorised go-live moves the platform from staging into production. It happens when the hardening is done, not on a marketing date.
First run on a live business
Rugene will first be used in the founder's own joinery business, day to day, to validate it on real work before it opens to external customers. That is real-workflow validation, not a customer count.
Planned
Every business, then scale
The scale path: one business at a time, then the wider trade.
The self-serve product layer
Tenant isolation is already in the architecture: each business's data is isolated from every other by design. What is planned is the self-serve product layer on top: a business signs up and configures its own products and labour times, so its estimates reflect how it actually works. Rugene logs the time; it does not run payroll.
From joinery outward
Prove it in UK joinery, the trade the founder knows cold, then extend to the wider trades. The goal Shane set: change how the trade prices and runs its work.
This phase is forward vision, tagged Planned. The foundation is built; the self-serve product on top is the planned direction, not a shipped feature.
An honest roadmap: the platform is built and running on staging today, with 37 of its 64 features live, and the AI factory that builds it is operational; production is deliberately parked pre-launch. What is left is planned and labelled: finishing the remaining features and hardening, a founder-authorised launch, first live use in the founder's own business, then a per-company build-out where each trade business onboards its own labour times, scaling from joinery outward.
Every item is tagged built, in progress, or planned. Built and in-progress items trace to live counts and verification; planned items trace to founder-stated direction. Launch carries no date by design. As at 2026-09-02.
The Story · The ask
Here is what I am looking for.
You have seen who I am, what Rugene does, and how it is built. Rugene is being shown for the first time here at Cloudflare Connect. If you bring the experience, money, or knowledge to help scale it into the business it can be, I would like to talk. I am open to investment, partnership, or both.
Two ways in
Investment
Runway, and more of my time on Rugene.
I run a 13 year joinery business, so I cannot walk away from it overnight. With a supportive business partner in that business, I can step back in stages, from four days a week to two, and put that reclaimed time into Rugene. Investment lets me make that move sooner: more dedicated founder time, parallel build capacity, and a faster path to launch. What the shape looks like is a conversation.
Partnership
A working platform that needs the right person beside it.
Someone with construction, software, or go to market experience who wants to help take a built product to market, or a technical partner who understands what an AI-engineered platform can become. You would be joining a substantial product already running on staging, not a slide of an idea. What you plug into, and what you get, is the conversation I want to have.
Where it honestly stands
Working software, not slides
37 of the 64 planned feature areas already have working implementations on staging. The rest are specced, part built, or planned. You have seen the current staging build in this deck, not a promise of it.
Customer zero is real
Rugene is validated against my own 13 year joinery business and close to 5,000 real jobs of estimating. I am not guessing at the workflow; I have lived it.
No paying customers yet
That is a deliberate sequence. In the trades, bad software costs real money, so I wanted it working and reliable before putting it in front of paying customers. The opportunity is to help take a working product, already used daily in a real business, to a market I know from the inside.
The next step
No forms and no follow up sequence. If one of these doors fits, tell me which one, investment or partnership, and what you would want to explore. Take the one page summary, or save my details, and reach out when it suits you. I would rather have one real conversation than a stack of business cards.
The one page summary carries the full contact details and a code you can scan to save them.
The close: Rugene's founder is open to investment, partnership, or both, in a platform already built and running and validated against a real joinery business. The next step is a conversation, with a one page leave-behind to follow up.
Every figure and claim is traceable to a source, a live count, or a founder-confirmed fact. As at 2026-09-03.
Reference · Glossary
In plain English.
A quick reference for the terms that come up, each explained in one plain sentence. An “agent” here is a specialised AI worker with one clearly-defined job.
The trade it comes from
The seven-stage problem
In most trade businesses the same job details get typed in again at seven stages: estimate, materials, purchase order, invoice, schedule, timesheet, then profit and loss. Rugene captures the job once and lets it flow through all seven.
Estimating (labour times)
Pricing a job by working out how long each task takes and what materials it needs. It is skilled, slow work; Shane has priced around 5,000 jobs by hand.
The machine that builds it
The AI factory
The system that builds Rugene: it researches, builds, tests, reviews and fixes in a loop, running mostly on its own.
The interrogation agent
Before a big decision it turns one question into twenty, surfacing what is missing, what is risky, and what connects to the rest.
The validation agent
A second opinion from three independent AI models, made by three different labs, used to sanity-check an important decision.
The Bullshit agent
A reviewer whose whole job is to catch the system overstating or claiming more than the evidence shows, what Shane bluntly calls not quite telling the truth. It scores the work and blocks anything it cannot stand behind.
The cross-model sentinel
On the highest-risk work, a reviewer built on a different AI model takes a fresh look. When the usual reviewers all agree, a different model often catches what they missed.
The blocker-resolution agent
When the system hits a wall, this agent decides whether it can fix the problem itself or whether it is a business call for Shane, and brings back options rather than just “stuck”. Shane calls it his “virtual Shane”.
The self-logged issue list
Every problem the system finds in its own work is written down and worked through; the ones that matter block a release until they are fixed. Nothing is quietly forgotten.
The technology, in plain terms
AI Gateway
Every AI request goes through one controlled doorway, on our own provider accounts and routing rules, so no outside middleman gets between us and the AI providers to see or reuse our prompts and our code.
Multi-model fallback
The system routes AI through a gateway that can reach more than one provider, and its own code falls back to a second provider if the first has an outage, so a single provider's bad day is far less likely to stall the build.
The knowledge base
A large, searchable store of what the system has learned, plus a connected map of past mistakes. It is searched before the system acts, so good patterns get reused and old errors are caught before they repeat.
Multi-tenant isolation
Each company's data is walled off from every other company's, enforced by the database itself on every request that touches that data.
A plain-English reference for the Rugene and AI terms in the deck: the seven-stage trade problem, the AI factory and its reviewer agents (interrogation, validation, the Bullshit agent, the cross-model sentinel, blocker-resolution), the knowledge base, the AI Gateway and multi-model fallback, and multi-tenant isolation.
Plain-English definitions of the terms used in this deck. Written to be read aloud.