→ continue
Keep building with us
The prototype works and you want it hardened, extended and rolled out. We carry on from the code that already exists.
thesix.dev / build log
One real problem. A working prototype in two weeks
thesix.dev is a group of Toronto developers experimenting with amazing things with AI. We run paid build sprints: you bring the problem, we ship software your own people can use and judge.
- Fixed price, agreed before day one
- You own the code
- Toronto-based
The sprint log, day by day: day 1, problem framed and success test agreed. Day 3, first ugly version running. Day 6, real data in. Day 9, your team is using it. Day 12, hardening and edge cases. Day 14, shipped: working prototype and handover.
Illustration of how a sprint is paced.
// 01 — the offer
“We should do something with AI.” Fine. On what?
You have heard it in a few meetings now. Nobody disagrees, and nothing gets built, because the idea is too wide to start and too vague to judge.
A build sprint makes it narrow. You bring one real problem from your own business. In two weeks we ship a working prototype: running software on your problem, with your data, that the people who would use it can actually try. Not a slide deck. Not a strategy document.
Then you decide, with evidence instead of opinions.
// 02 — the sprint in six moves
Six things you get.
- 01
One problem, well chosen
We spend the first day narrowing a broad hope to a single task that is worth solving and small enough to finish.
- 02
A success test, agreed on day one
Before anything is built we write down how you will judge it. The result is measured against that test, not against our enthusiasm.
- 03
A demo every few days
You see running software early and often, so a wrong turn costs an afternoon, not a month.
- 04
Your real data, handled carefully
Prototypes that only work on invented examples prove nothing. We agree up front what data is used and how it is treated.
- 05
A working prototype, not a deck
Something your own people can open, use and push on. That is the deliverable.
- 06
The code and a straight answer
You get the code, and an honest view on what to do next: keep going, bring it in-house, or stop.
// 03 — why two weeks
Long enough to build something real. Short enough that being wrong is cheap.
Two weeks is enough to get past the demo-that-only-works-on-stage stage and put real data through real software. It is also short enough that if the idea turns out to be weaker than it sounded, you find out now, while it is still a small decision.
You spend two weeks instead of two quarters finding out.
A build sprint
2 wks
Two quarters
26 wks
// 04 — the kind of problem that fits
Narrow, repetitive, and easy to judge.
Examples of problems that suit a two-week sprint. They are illustrations of the shape, not a list of things we have shipped.
01Reading and routing inbound documents02Answering customer questions from your own knowledge base03Turning call notes into CRM updates04Drafting quotes from past jobs05Checking data before it goes out the door06Summarizing long threads for the person who has to decide07Matching messy records across two systems08Pulling structured fields out of forms and PDFs
// 05 — quick check
Is it a sprint-sized problem?
Four questions about the problem you have in mind. It runs in this page and nothing is sent anywhere.
Q1Can one person describe the task start to finish?
Q2Is there real data or documents we can use?
Q3Would a person recognize a good result when they see it?
Q4Is someone on your side free for a few hours a week?
0 of 4 answered
Answer the four questions
Your verdict builds as you go. There are no wrong answers, only a clearer picture of where to start.
// 06 — after day 14
Three ways forward. All of them are fine.
→ handover
Take it in-house
You own the code. We hand it over with notes, and your own developers or another team take it from here.
→ stop
Stop
If it turns out not to be worth building, you have your answer, and we tell you why. You spent two weeks, not two quarters.
// 07 — how we work
A small senior group, based in Toronto.
We are developers first. We use AI heavily in our own work, every day, and we show you how as we go, so your team comes out of the sprint knowing more than when it went in.
Toronto is home, and where we prefer to meet in person. You will work with the people building your prototype, not a layer of account management.
- team
- small, senior, hands-on
- where
- Toronto, in person where it helps
- pace
- a demo every few days
- price
- fixed, agreed before day one
- code
- yours
// 08 — questions
Straight answers.
Who owns the code?
You do. The prototype is built for your company, and the code is handed over at the end of the sprint.
What does it cost?
Fixed price, agreed before day one. You know the number before any work starts, and it does not change as we go.
What if it doesn’t work?
Then you found out in two weeks, and we tell you why. A clear “not this, not yet” is a useful result. It is far cheaper than discovering the same thing after a long project.
Do we need to be in Toronto?
It is our home and where we prefer to meet in person, so Toronto companies are who we are set up for.
What do you mean by a working prototype?
Running software, on your problem and your data, that your own people can use and judge. It is not production-hardened at scale, and it is not a mock-up. It is the real thing, small enough to finish in two weeks.
What do we need to bring?
One real problem, access to the data or documents it touches, and someone on your side with a few hours a week to answer questions and try what we build.
// 09 — day zero
Bring us a problem.
One sentence is enough to start. We will reply by email to talk through whether it fits a two-week sprint, and if it does not yet, what the first slice could be.