Research first
We look at the problem, the market, what already exists and what is open source before committing to a stack. A project is allowed to stop here.
How we build · free brief builder below
Project Factory: from idea to audited build
Every SlickLab project follows the same 12 phases. Research comes before the stack is chosen, the architecture comes before any AI agent, and nothing is called finished until an audit run by code says so.
The rules
Three rules we do not skip
Architecture before agents
Identity, permissions, calculations, state changes and anything involving money are ordinary code. AI is added only where reasoning helps.
Two packages, not one
You get a complete private baseline. A separate public package shows what the product does without giving away how it works.
The lifecycle
Twelve phases, each with something to show for it
Coding starts at phase six. By then the problem, the scope, the boundaries and the architecture are written down and agreed.
The problem, who has it, what it is worth, the business model, and what the project will not do.
The market, comparable products, open-source options and integrations, each claim with a source.
Users, workflows, the first version, later phases, pricing, and how success is measured.
Which service owns which data, the interfaces, permissions, deployment, monitoring and rollback.
Every artifact is marked public, internal, confidential or secret before more is written.
The core workflows you can click through, on a phone, including empty and error states.
AI agents only where reasoning helps. Each gets a written job, tools, limits and tests.
Contracts, policies, evaluations and runbooks that match real permissions and real tests.
Feature, security, permission, failure-path and leak checks, run by code and reported with evidence.
A version, a hash of every file, the audit report, and a package you can roll back to.
What it does, a safe demo, ownership and licensing. The methods stay private.
Real services and integrations, a staged rollout, telemetry, and automation that stays supervised.
Flow
Pick a step
Select any step to see what happens there, or play the flow. You can drag the steps around; Reset puts them back.
Authority first, intelligence second
What code decides and what AI is allowed to do
An agent can read, interpret and draft. It cannot approve, charge, book or change a record on its own. The code checks its output and has the last word.
| Always ordinary code | Where an AI agent can help |
|---|---|
| Sign-in and permissions | Researching a question |
| Calculations and prices | Reading free text and pulling out the facts |
| Changes of state, such as a booking or an order | Summarising and explaining |
| Payments and refunds | Planning and suggesting alternatives |
| Secrets and the audit record | Looking into exceptions for a person to decide |
The audit gate
Ten checks run by code, not ticked by hand
A checklist anyone can tick proves nothing. Each check below runs against the real project folder and reports the evidence it used. Questions that need judgment are flagged for a person and are never passed automatically.
- Secrets scan. No keys, tokens or passwords anywhere in the project.
- Credential files. No .env, key or certificate file is included.
- Non-goals written. The brief says what the project will not do.
- Research sourced. The research has real links, not placeholders.
- Contracts present. Tool and event contracts exist and are filled in.
- Agent definitions complete. Every agent lists its allowed and forbidden tools.
- Agent tools contracted. Every tool an agent may use has a written contract.
- Tool contracts complete. Each contract states inputs, outputs, permissions, side effects and failure modes.
- Evaluation coverage. Six kinds of test exist: normal, edge, failure, adversarial, privacy and authority.
- Rollback runbook. There are written steps to undo a release.
A worked example: our Inbound Lead Conversion system went through this gate. It passes all ten checks, and its baseline is frozen with a hash of every file.
Public and private
Show what it does. Keep how it works.
The public package is built from an allow list, then scanned again for secrets and private material before it leaves.
| Artifact | Private baseline | Public package |
|---|---|---|
| Capabilities and outcomes | Yes | Yes |
| A safe demo on sample data | Yes | Yes |
| High-level architecture | Yes | Yes |
| Licensing and how to buy | Yes | Yes |
| Agent instructions and prompts | Yes | No |
| Scoring rules and internal workflows | Yes | No |
| Credentials, infrastructure and client data | Secret store only | No |
Free tool · no email
Draft your project brief
Fill in what you know. You get a one-page brief and the questions still open before anyone should write code. It is built in this browser and nothing is sent.
Work with us
Want your project run this way?
Bring the brief, or just the idea. We will tell you plainly whether it is worth building, and what the first version should be.