TURN AN IDEA INTO A WORKING PRODUCT
Form your team, build the product, test it in real use and keep it alive.
Build is the path for turning a confirmed need into software, a game, media, learning, a tool, a service or a field application. Work in small releases, learn from real people and take responsibility for maintaining what you make.
Team · Product · Release · Real Use · Care
My place in the ecosystem
Production that works and continues
Turn a confirmed need into a product or service that people can use.
Build is the production path after a successful prototype. The team agrees the scope, makes a working release, tests it in real use and establishes responsibility for care after publication.
A product is complete not when it is published, but when people can use it and its future is carried.
The production path
Take on the need, make a working release and establish what comes next.
Build does not end with an impressive demo. The team makes a small version that real people can use, then makes errors, support needs and the next decision visible.
Take On the Need
Agree who you are building for, what the first release will cover and how the team will recognise useful progress.
Make a Working Release
Develop the content, data, software, game, device or service in small parts and show progress regularly.
Establish the Future
Set up user support, documentation, a maintenance lead and the next publication or service route.
Who builds together?
Bring people who understand the issue together with the skills needed to make the result.
A Build team may include field practitioners, researchers, designers, developers, content makers, people testing the work and those who will maintain it. Roles change with the product; the aim is to unite different skills around real use.
A good product does more than work: people can understand it, use it and carry it forward.
What Build is not
Not prototype scaling, a coding sprint, a product department, a delivery factory, a startup accelerator or another name for Builders.
A working demo, many features, fast delivery or a visible launch do not make a complete Build without rights, safety, usability, maintenance and handover.
Not prototype scalingDo not simply expand the scope before the Lab result has been repeated and acceptance measures are clear. Not a coding sprintSoftware is one production path; it must not swallow field knowledge, data, media, learning, devices, places or professions. Not a delivery factoryClosing tasks is not the same as protecting the rights of real users and understanding what happens in use. Not a startup acceleratorInvestment, growth and launch are not the primary purpose of Build. Not a one-off projectMaintenance, issues, security, support, closure and handover after release are part of Build. Not another name for BuildersBuild is a process. Builders are people who carry skill and responsibility within this and other production processes.
From a real issue to a working product
A Mission carries the need, a Lab shows what works and Build carries the route to something people can use.
An idea does not move straight into production. First confirm the real need and a small trial; then begin a Build with clear scope, team and responsibility for care.
Mission and Lab
Prepare the need and the trial
- Know the real users and need
- Test the main idea with a small prototype
- Hand over the learning and open risks
Build
Make the working product and keep it alive
- Make the smallest usable release
- Test and correct it in real use
- Establish maintenance, support and handover
The Build team
Build is shared work between people who know the need, make the result, use it and carry its future.
Field knowledge, real use, maintenance and communication belong in the team alongside code, design, content or devices.
Build Lead
Keeps the scope, team, timetable and expected outcome aligned.
Production Team
Develops the code, data, design, content, device, place or service components.
User and Field Voice
Keeps the real need and conditions of use present throughout production.
Field Guide
Brings the quality and use standards of the relevant profession or subject.
Rights and Safety Lead
Keeps privacy, consent, security and misuse risks visible.
Maintenance Lead
Carries support, updates, handover and closure after release.
Move forward in small releases
Do not wait for one large delivery; make small releases that real people can use.
In every cycle, make, test, gather feedback, correct and record what you learn.
Choose a Thin Slice
Select the smallest meaningful journey a real user can complete.
Make and Document
Record sources, decisions and versions alongside the code, content, data, device or process.
Test with Systems and People
Automated technical tests do not replace testing with people, field practice and professional knowledge.
Review Real Use
Invite feedback from people with real experience, context, rights and the ability to object.
Correct and Test Again
Do not simply close an error; record its cause, effect, correction and the result of the new test.
Make the Next Decision
Decide whether to continue, narrow the scope, return to a Lab, stop or prepare a release.
Build production paths
Software, media, machines, learning, places or services: Build is open to different kinds of production.
Each path brings its own expertise. The shared goal is a result that people can use, understand and continue.
Software, Data and Models
Code, datasets, models, agents, APIs, security, evaluation, export and human intervention.
Media and Representation
Sources, permission, synthetic elements and publication context in text, image, sound, video, games and interfaces.
Machines and Devices
Mechanics, sensors, firmware, physical safety, maintenance, manual control, recall and end of life.
Learning and Programmes
Curriculum, Circles, guides, age, assessment, workload, rights, accessibility and continuity.
Places, Farming and Craft
Materials, buildings, soil, water, food, handwork, safety, local maintenance and seasons.
Services and Organisations
People, roles, schedules, payment, communication, complaints, records, quality and handover.
Quality is more than looking good
A good product should be accurate, understandable, accessible, resilient and maintainable.
It matters whether people can understand and use the work in different conditions—and whether a new team can safely take over its care.
Accuracy and Sources
Are claims, data, translations, model contributions, uncertainty and freshness clear?
Understandability
Can people understand what it is, what it is not, how to use it and when to stop?
Accessibility
Are there alternatives for barriers involving language, disability, device, connection, age, cost and care?
Resilience and Performance
Have real load, errors, outages, old versions, device failures and provider shutdowns been tested?
Documentation and Learning
Can a new team set it up, use it, change it, inspect it and close it safely?
Care and Courtesy
Do support, error messages, communication, refunds, complaints and closure treat people with dignity?
Before release
Open a product to wider use only when real use, rights and responsibility for care are ready.
The team makes the conditions of use, sources and permissions, safety route, support lead and—when needed—the ability to withdraw the product visible.
Acceptance and UseHave critical journeys been tested with real people and met their acceptance measures? Sources, Rights and LicencesAre the rights for code, data, models, content, materials, supply and publication clear? Agreements and SafetyAre payment, liability, privacy, security, child safety, representation and remedy ready? Quality and AccessibilityAre accuracy, clarity, language, access, performance and user support ready? Operations and RecallAre monitoring, issues, support, security reporting, rollback, stopping and recall ready? Maintenance, Budget and OwnerAre the responsible team, period, budget, closure and handover after release clear?
After the product is released
Build continues through maintenance, updates, support and safe closure.
A product becomes orphaned when its owner, budget, error-reporting route or future team is unclear.
Maintenance Lead and Budget
Who will maintain it, for how long, with which resources and decision-making authority?
Issues and Security Reports
Can errors, harm, security concerns and rights violations be reported and tracked easily?
Versions and Change
Are changes, migrations, old versions, model updates and user notices recorded?
Export and Portability
Can data, documents, code, models, device settings and user records move safely to a new owner?
Closure and End of Life
How will rights, data, debts, materials and the environment be protected when the work closes?
WAQF and a New Team
How far should methods, sources, documents and maintenance knowledge be opened so qualified people can continue the work?
When a real Build period opens, its subject, team, duration and participation conditions will appear here.
Meeting format
- — Team production period
- — Build workshop
- — Field-based Build
Duration and rhythm
- — Regular production and user meetings
- — Need → small release → real use → revision → maintenance decision
- — A typical Build may run for 4–12 weeks; the actual duration is published with each programme.
Who carries it?
- — Need and programme lead
- — Builder team
- — Expert or master in the field
- — User or field participant
- — Maintenance lead
Current status
No open cycle · preparation continues
This page explains the programme model. Dates, capacity, team and a working application path will be published together when a real cycle opens.
Safety and responsibility
Before work begins, the team makes consent, privacy, child and family safeguards, professional limits, misuse, error reporting, suspension and withdrawal conditions clear.
Intended outputs
Choose a new issue
Find a real need and a team through Missions for your next production journey.
Missions are the starting point for making clear why something should be made, who it is for and what change it should carry.