AI Hackathons and Build Sessions
The build is the easy part. Monday is the hard part.
What is build sessions?
A build session is one or two days in which your own teams build working prototypes against real problems from your business, ending with a decision about each one rather than a demonstration and applause.
Most hackathon output never ships. The usual explanation is that a day is not long enough to build anything real, which is only half true. The bigger reason is that nothing was decided about what happens next.
A day produces a prototype. A prototype becomes a product when somebody owns it, a budget exists and a real decision was made. None of those happen during the building, and none of them happen by themselves afterwards.
So the day is built around ending well. Real problems chosen because they can survive contact with Monday, and a closing session that produces owners and decisions rather than a winner and a photograph.
What a day can and cannot produce
Duara runs build sessions in Nairobi for organisations wanting their own teams to build something against their own problems.
We do not promise anything production ready in a day. What a day produces is a prototype and a decision, and pretending otherwise is how organisations end up with a folder of demonstrations nobody ever used.
Who this is for
- You want your team building rather than listening
- Several ideas need testing cheaply before committing
- Internal teams need momentum on AI
- Previous innovation days produced nothing lasting
Industries we serve
- Banking and financial services
- Telecommunications
- Technology companies
- Manufacturing
- Retail groups
- Universities and research
Problems this solves
These are the reasons build days produce demonstrations that go nowhere.
- Nothing decided at the end. Teams build, everybody applauds, and the prototypes sit untouched because no owner or budget came out of the day.
- Invented problems. Teams work on made up scenarios, so nothing built has a route into the business even when it works well.
- Demonstrations that flatter. A prototype shown on chosen input looks finished, and the same thing meets real data the following week.
- The flashiest thing wins. Judging rewards presentation over usefulness, which sends the wrong signal about what the organisation values.
What we deliver
Real problems chosen for their route into the business, data prepared beforehand, technical support in the room, and a close that produces owners and decisions.
Working prototypes rather than slides
Real problems from your own business
Your own data prepared before the day
Facilitation and technical support throughout
A named owner and decision for each build
An honest note of what each prototype does not do
Features
- Problems chosen for survival. A problem where the data already exists and somebody owns the process can continue on Monday. One without those cannot.
- Data ready before the day. Teams spending the morning hunting for data build for four hours instead of eight, which is the most common way a day is wasted.
- Support in the room. Technical help available throughout, so a team stuck on a connection problem does not lose the day to it.
- Closes with decisions. Each build ends with an owner, a next step or an explicit decision to stop, rather than with applause.
- Limits recorded, not hidden. What each prototype does not yet do is written down while everybody still remembers, since that list is what a decision needs.
Benefits
- Ideas get tested cheaply. A day is a fast way to find out whether something is worth building properly, including the ones that are not.
- Your team builds capability. People who have built something with these tools judge proposals about them far better afterwards.
- Fewer orphaned prototypes. Owners and decisions at the close are what separate a build that continues from one that sits in a folder.
- Bad ideas die early. Establishing that something should not be built is a genuine result and considerably cheaper than finding out later.
What teams have on the day
- Real problems from your business. Framed and chosen beforehand, since choosing on the day costs hours nobody has.
- Prepared data. Extracted and sanitised in advance, because hunting for it is the most common way a build day is wasted.
- AI tools usable in a day. Chosen for what a team can genuinely get working in the time rather than for capability alone.
- Technical support in the room. So a team blocked on a connection or a credential does not lose the day to it.
- A closing decision session. Structured to produce owners and next steps rather than a winner and applause.
The single biggest determinant of a good build day is preparation that happens before it. Teams that arrive to prepared data and a clearly framed problem build for a full day, and teams that do not lose the morning.
How the process works, step by step
Build sessions run one or two days. The preparation beforehand is what determines whether the day works.
-
Step 1
Free problem review
We look at candidate problems and say which ones can survive past the day and which cannot.
-
Step 2
Data prepared in advance
Extracted and sanitised before the morning, so teams build rather than hunt.
-
Step 3
Teams built deliberately
Mixed skill levels, since the person who knows the process matters as much as the person who can code.
-
Step 4
Building with support present
Facilitation and technical help throughout, so blocked teams get unblocked quickly.
-
Step 5
Closing decisions recorded
Each build gets an owner, a next step or a decision to stop, written down before people leave.
Quality assurance and how we work
The commitments attached to a day your teams give up to build something.
- We do not promise production ready output. A day produces a prototype, and pretending otherwise is how organisations collect demonstrations nobody uses.
- We say which problems are wrong for the format. A problem needing data you do not have, or access to a system nobody in the room controls, will not survive the day.
- We say when a hackathon is the wrong instrument. If you already know what you want built, a build day is an expensive way to start building it.
- We write down what prototypes cannot do. The limits are what a decision needs, and they are forgotten within a week if nobody records them.
- We judge on usefulness rather than presentation. Rewarding the flashiest build tells the organisation the wrong thing about what it values.
Frequently asked questions about build sessions
Why does hackathon output usually go nowhere?
Because nothing was decided at the end. A prototype becomes a product when somebody owns it and a decision was made, and neither happens by itself.
Can we get something production ready in a day?
No, and we will not promise it. A day produces a prototype, which is a thing worth having provided nobody mistakes it for a product.
What makes a good problem for the day?
One where the data already exists and somebody in the room owns the process. Without both, the build cannot continue on Monday.
What makes a bad one?
Anything needing data you do not have or access to a system nobody present controls. Teams spend the day blocked rather than building.
Do we need to prepare data beforehand?
Yes, and no single decision affects the day more. Teams hunting for data build for four hours instead of eight.
Should non technical people take part?
Yes. The person who knows how the process actually works is often more valuable to a team than another developer.
What does a successful day look like?
Every build has an owner, a next step or an explicit decision to stop. A day producing three stop decisions has still worked.
Is deciding not to build something a failure?
No, and it is frequently the most valuable outcome. Finding out early is considerably cheaper than finding out after six months.
How do you judge the builds?
On usefulness rather than presentation. Rewarding the flashiest tells the organisation the wrong thing about what it values.
One day or two?
One day suits a single problem. Two allows several teams working in parallel and gives time to recover from a wrong turn.
Can it be an internal capability day instead?
Yes, where the aim is momentum in your team rather than output. The format shifts and we would say so upfront.
Do teams need to know AI already?
No. Tools are chosen for what a team can genuinely get working in a day rather than for capability alone.
Do teams have to be in one room?
It works far better that way. Building depends on people overhearing each other and getting unstuck fast, which a call does not reproduce.
How many teams can run at once?
Several, with two days giving each of them room. The constraint is support in the room rather than space.
Is our real data safe to use?
We use sanitised extracts, with sensitive fields removed beforehand, so teams work with something realistic without the exposure.
What happens to the code afterwards?
It is yours, along with the written note of what each prototype does not yet do.
Can you continue building afterwards?
Yes, where a build is worth continuing. That is a separate piece of work and a separate decision rather than an assumption.
Would you tell us not to run one?
Yes. If you already know what you want built, a build day is an expensive way to start building it.
Who sees our business problems?
The facilitators and your own people, under whatever confidentiality arrangement you require, agreed before the day.
What does a build session cost?
Days, team numbers and preparation determine it, quoted after the problem review and before you commit.
Glossary of terms
Build session terms in plain language.
- Prototype
- Something that works enough to judge, which is not the same as something ready to use.
- Problem framing
- Turning a vague frustration into something a team can build against in a day.
- Sanitised data
- Real data with sensitive fields removed, so teams work with something realistic safely.
- Owner
- The named person responsible for what happens to a build after the day, without whom nothing happens.
- Demonstration effect
- How a prototype shown on chosen input looks more finished than it is.
- Closing session
- The structured end of the day where decisions and owners are recorded rather than prizes awarded.
Related services in AI Events
Talk to us about build sessions
Pick three problems where you already hold the data and somebody owns the process. Those are the ones worth a day.
Start your project