The operating
system for
finished work.

Get your best version

One model should never be the sole judge of its own output. A persuasive response is not evidence. Agreement from the same underlying intelligence is not independent review.

sneferu · run 7f3a · spec → buildRequest
The request

A dispatch system for a 40-truck HVAC fleet: parts inventory, route planning, and it has to work offline on a tablet.

Snef
stages the run · spec → build
Cast
four model families, five seats
Cap
$60.00 · estimates are never charged
Three drafts, three model families
Draft Amodel 1 · route-first
Draft Bmodel 2 · inventory-first
Draft Cmodel 3 · dispatcher-first
Independent critics attack every draft
  • AOffline sync unproven→ obligation
  • BIgnores the parts inventory✕ dropped
  • CRoute math can’t be verified✕ dropped
  • JudgeKeep Draft A. Resolve the objection.a fourth model decides
Evidence decides, not the models
  • Tests42 passed · 0 failed
  • Installs cleanfresh machine · no internet
  • Starts uprunning in 1.8 s
  • The real task worksjob dispatched offline · synced later
Finished
Delivered · dispatch v1 fingerprint 9c41…e7f2

With the receipts: three drafts, every objection, the tests, the cost, and the version you tried.

One run, in about thirty seconds. An illustration, not a live feed.
Built by Sneferu

No model grades
its own work.

Most AI systems let the same intelligence write the answer, review it, and announce it’s done. Sneferu was built on the opposite rule, and everything else follows from it.

Independent minds.

Models from different training lineages get different jobs: author, adversary, reviewer, scorer, judge. Disagreement is part of the process, not a bug to smooth over.

Evidence decides.

Tests, validators, real data, and runtime checks can overrule every model in the room. A persuasive answer is not a finished one.

It keeps the receipts.

Every run leaves its decisions, objections, tests, costs, and failures on the record. You inspect how the work earned completion, not just the last answer.

Software. Businesses.
Research. Games.

Research is not a coding task. A business is not a chat. Each kind of work gets its own production line, with the same engine and the same evidence underneath.

Sneferu Coders

The specification is argued to convergence first. Then an implementer, a pair coder, and an independent reviewer work inside the real project, with tests and validators feeding every failure back until the evidence passes.

Software On Demand build screen asking what Sneferu should build Actual build screen · Software On Demand · Select image to enlarge
Software On Demand

Tell it what to build.
Try the proven app.
Then decide.

Describe what you need. Rival models argue the specification until one survives and you approve every word. Sneferu Coders build it. Before you see it, it’s tested, installed clean, and started. You try the real thing, ask for fixes, accept the version you tried, and pay for the work done.


Check it out
A root specification agreed inside the Software On Demand workspaceActual SOD workspace · an agreed specification ↗

Three attempts.
One direction.

Around 2600 BC the pharaoh Sneferu set out to build something nobody had built: a true, smooth-sided pyramid. It took him three tries.

  1. 01
    Meidum. The first began as a stepped pyramid and was reshaped, late, into a smooth one. Its casing is gone; how it came off is still argued.
  2. 02
    The Bent Pyramid. The second started steep. Partway up, the ground gave way: 23 centimetres, measured, still visible. The builders plastered the cracks, changed the angle from about 54° to about 43°, kept going, and then walked away.
  3. 03
    The Red Pyramid. The third, built at the shallower angle from the ground up, worked: the first true smooth-sided pyramid brought to completion.

Sneferu kept building until he got it right. That's the company.

The Sneferu mark: three forms, early to finishedNever. Give. Up.

Self-improvement.
With the receipts.

Sneferu builds tools for its own next round of work: memory that carries context forward, and a workshop for making models better.

A few useful answers

Before you
begin.

Ask us something
Is Sneferu a model or a coding assistant?

Neither. Sneferu is the system around the models: planning, execution, tools, memory, review, and recovery. Software is one kind of work it finishes. Businesses, research, and games run on their own production lines on the same system.

Is Sneferu like Claude Cowork or GPT Work?

No. They are perfect complements. Use Sneferu to get the best specification you can get anywhere for your V1, and let Sneferu build it. Becuase, why not? Then hand it to your vibe coders to customize to your heart's content.

Why different models?

Different model families have different blind spots. Sneferu gives them different responsibilities and lets independently trained lineages challenge the work. Agreement alone proves nothing. Tests, validators, real data, and runtime evidence can overrule every model in the room.

What does “finished” mean here?

The outcome met the checks for that kind of work. A software build needs execution evidence; a research claim needs support the system tried to refute. A completed run is not automatically a qualified product, and Sneferu says so. Remaining problems stay on the record instead of disappearing.

What is Snef?

Snef is the Sneferu Brain: the operator you talk to. It reads the state of the system, uses memory and tools, and turns a goal into a plan and the right kind of run, with permissions and launch controls intact.

Where can I see how it really works?

Inside Sneferu walks through every named part in plain language. The System Atlas maps the architecture, relationships, and implementation.

How can I work with Sneferu?

Software On Demand is to demonstrate the bigger Sneferu platform, which can run entirely air-gapped if needed. To learn more about Sneferu, potential use, research collaboration, or a partnership, contact me.

Let’s put it to work

What would
you build?

Built by Michael Lange.
Founder, Sneferu.ai, Inc.

Contact me

Projects, research, platform access, and partnerships.

Goes to the founder. Not a mailing list.

Built with Sneferu / Education & commerce

Life Skills
Foundations.

A request for the things school leaves out became a family curriculum and the software to deliver it.

Life Skills Foundations storefront and curriculum modules

The product

Age-banded lessons, printable PDFs, a storefront, and Pilot Deck: a console for preparing and tracking a 40-family pilot.

The starting point

The operator supplied the concept directly. The Idea Bloom was deliberately skipped; complete ideas go straight to the specification.

Pilot Deck operator dashboard, with the pilot not yet started

Pilot preparation snapshot: the 40-family launch has not started; checkout still needs configuration.

Built with Sneferu / Shop operations

Restoration
Copilot.

A working core for the many moving parts of a classic-car restoration shop.

Restoration Copilot photographic intake and known-components form

The product

Photographic intake, vehicle state, a parts knowledge base, sourcing, purchasing, budget checks, and a mobile Bay Guide.

Human control

Budget checks, purchasing records, and audited decisions keep the consequential shop actions in the operator’s hands.

A Camaro project in Restoration Copilot with intake open
Built with Sneferu / Software On Demand

FlowForge
Open.

Workflow automation for freelancers and small agencies, with a real API to explore.

FlowForge Open API displayed inside the Software On Demand preview

The product

Workflow manifests, schedules and webhooks, manual approvals, and metered runs. The API includes workspaces, members, triggers, credentials, audit, and billing surfaces.

The SOD experience

The recorded Preview & Test workspace puts the running API beside its documentation, so the operator can inspect the build before accepting it.

See how Software On Demand works
Built with Sneferu / Infrastructure

ESM.
Memory with a history.

Governed long-term memory for Sneferu, and for other AI applications. A memory service that keeps track of what an entry means, where it came from, and how it changed.

More than saved text

Facts, preferences, decisions, and warnings are typed entries with provenance and confidence. Related memories are retrieved as context for later work.

Change without amnesia

Conflict checks surface clashing claims. Supersession, review, and retirement let the system update what it remembers while preserving the trail.

Typed intakeConflict checksGoverned storageRecall

A separate memory service with a FastAPI interface and Postgres / pgvector storage. The diagram describes its architecture, not a live activity feed.

Meet the system that uses it
Built with Sneferu for Sneferu / Model improvement

FDC Studio.
Better has to be proven.

Sneferu built a workshop that studies a model’s failures, finds the training examples it needs next, and tests whether a new version deserves to replace the old one.

The recorded demo uses simulated model responses. It demonstrates the decision process and rejection of bad candidates, not a completed production fine-tune.

FDC Studio campaign history with one accepted improvement, two rejected attempts, and the last good model retained Open the full-size decision screen

Focused improvement

Test the model. Group recurring mistakes. Gather traceable examples for those weaknesses. Mix in earlier examples to protect existing skills, train a candidate, then evaluate it on a separate test.

One kept. Two rejected.

The bundled demo runs three attempts against a fixed 120-item test. One improvement is accepted; two are rejected. It ends with 36 traceable training examples and the last good model intact.

Every decision leaves a record.

The audit ledger records 33 events, including the accepted improvement and both rejected attempts. The final candidate made tool use worse, so FDC kept the previous version.

FDC Studio audit ledger: 33 events, one promotion, and two rejected attempts restoring prior state Open the full-size audit ledger

The original request

“Invent a novel fine-tuning method for optimal LLM performance in a target domain.” Idea Bloom explored 156 approaches; three survived the argument. The chosen direction became FDC Studio through Sneferu’s specification, code, and test pipeline.

A connected workshop

The design connects the model being improved, independent judges, search tools, human experts, and a training system. Training and the decision to promote a model stay separate.

Sneferu Idea Bloom with Failure-Directed Targeted Corpus Construction selected from 156 explored approaches Open the full-size Idea Bloom

Screenshots and demonstration record preserved from the original Sneferu site, reviewed August 23, 2026.