Build Sessions: A one-day hackathon
6 technologists spend a Saturday turning their ideas into working products. Here's how it went and how you can do it, too
This April, six technologists spent one Saturday at Build Sessions, turning ideas that had been floating around in heads and voice notes into things they could hold, show someone, and release to the world. By the time we got to demos, one team had saved each other as co-founders. They’d met at a previous meet-up, now they were building together.
This is the story of how I hosted and participated in Pivotech’s first hackathon - Build Sessions. I’ll share what we learned, what we built, and what’s next.
Before we go into it, Pivotech’s next session will be a demo day where these builders will get to demo what they’ve built and the traction they’ve gotten so far. There will be demos and time for you to talk, geek out, and connect people you can build with. Sign up here to receive an invite!
Wednesday: Conversations with Technologists
Before building, we had to get our minds right.
We kicked off the week with a Conversations with Technologists (CWT) session on building, fast and slow. This session showed us different frameworks and timelines for turning an idea into reality.
To begin, a co-founder duo spoke to us about what they were building to solve renter misalignment in the rental industry. They shared what building looks like when the industry has legal considerations and is driven by legacy behaviour i.e. lots of research, having an industry expert as a cofounder, and pilot studies. We dug into how their product would work and how it would extend the industry.
This session clarified what building actually involves. Increasingly so, the challenge is not the technical implementation but the clarity on what the product is, how it will get to customers, and how it will fit within (and hopefully transform) the wider industry landscape. From there, the technicals are just a bridging of the gap to reality.
Next, we had three sessions to equip us with technical skills that would help us during building. They were on:
Product discovery and scoping, and building an effective team (by Daniel Adewunmi)
Design as a way of making an idea feel real, fast (by Uche Onyeka)
Spec-driven development as a paradigm for building with AI, (by Nkechi Anyanwu)
Finally, we chose our teammates, discussed some ideas we’d saved in the group idea bank, and ended the session with so much energy and excitement that I knew Saturday was going to be a blast. And it was.
Saturday: Build Sessions
Finally, Saturday came, and it was time to build!
I’ll explain the approach we used in building, share what I’ve learned as an organiser and participant, and show some memories from the day.
Block A: Ideation:
Before you ever start building, you need clarity.
What are you going to build? Who is it for? What are the flows that provide value? We answered four questions to frame what we were going to build:
What is it?
Who is it for?
What are you building for your MVP?
What are you not building?
The Idea Selection Process
I thoroughly enjoyed this because my teammate and I got to explore and pressure test ideas we’ve had in our vaults for a while. The process was fun - we used notebooks, meeting recorders, and sticky notes, and visually mapped out our ideas. We also got to riff off of each other and connect intellectually. I felt very inspired during this process.
These are some of the ideas we explored. I’d like to share the thinking behind why we decided to build (or not to build) them as a way of framing the different categories of products that exist and how to recognise what is required of each (e.g. skillsets, research, industry expertise, insider knowledge):
Idea A: This was a trendy idea but it had no moat and would take a long time to get running. It also felt more like an AI workflow than a product.
Decision: Still an interesting idea, but not one to spend a hackathon on.
Idea B: This was an investment management product that initially sounded promising, but our research showed the market was well-served (too competitive) and there was a lot of industry expertise / jargon that meant we would need an actual investment manager to build and test it.
Decision: Decided to pass. We could still build it, but not without an investment management cofounder, and a lot more research.
Ideas C and D: Both interesting ideas with same core problem - they were software wrappers over an operations business. These were the most seductive because they framed themselves as marketplace matching solutions, but when we started talking about them, we realised changing the industry behaviour would require us to have a large back office doing the work before it could take off. It also meant any demo we did would be largely hypothetical.
Decision: Not for a hackathon. Seems like one for more time and investor funding.
Final choice: This initially seemed too simple (not ambitious enough), because we were so familiar with the problem that it didn’t feel like a challenge to build. After cycling through other ideas and realising we didn’t want to spend time on them, we decided to give this one a second look. We realised our familiarity with the problem actually gave us intuitive solutions for how to solve it, and we saw immediate ways of testing it ourselves, and with others. It was doubly interesting because I came with one perspective of the problem, and my teammate came with another. This made it a well-rounded solution to the problem.
Decision: We have our winner!
Block B: Building and Demoing
This was the shortest phase, but only because we were incredibly clear on what we wanted to build. If you have the mindset that idea clarity precedes the build, then your execution will simply be the bridge from idea to reality. Note that this doesn’t mean there’s no joy in building something technically sound and elegant! It just means you know exactly what you want to build.
We created a Product Requirements Document (PRD) to codify what we were building and scoped out the high level technical implementation. This started with us designing the data model and ontology for the product, which maps the idea to the shape of the data it needs to exists, and the concepts that are involved in the product. This was important because:
Your data model encodes the logic of your product. Finalising it early means your logic is more likely to be sound, and your building will be more effective
The ontology gives you the naming conventions and concepts for what you’re building, which makes it intuitive for reasoning about how various parts of your product interact with one another and your user. It helps you think of your product from the position of it actually working and being used
A defined PRD makes it easier to scope what you are building. You’ll know exactly what parts of your proposed product is the core flow, what parts can be left for a later version, and what parts are unnecessary
We then split up to work on different parts of the implementation plan, with my teammate creating the visual language while I researched on how to implement the backend logic. Once we finalised our implementation plan, we gave it to a coding agent to execute, and a few minutes after, we had our working MVP! This was practically one-shotted by the agent because we were opinionated on how we wanted this to be built, and we scoped the build to the core value proposition.
Finally, we had our demo and showed the other teams the manifestation of the idea we started the day with. We also watched other teams demo their ideas, and discussed our plans for continuing our builds.
Memories:
I can’t overstate how fun this was.
As a participant, I was doing something I thoroughly enjoyed with other passionate, excited builders who also wanted to spend a Saturday ideating and building. To top it all off, I left with a renewed confidence in my ability to build future ideas, a working framework for tackling new projects, and a new side-project I’m excited to build!
As a host, it was deeply satisfying to see all the work I had put into organising this pay off. I watched people who had started off as strangers build delightfully wonderful products together. I got to experience their creativity and excellence as they turned their ideas into things. I felt incredibly proud.
Here are some memories from the day:
Busy building:
Chat agents doing what chat agents do…
Lunch was a delightfully silly side quest going through a food market and trying Senegalese, Nigerian, and Jamaican food. It gave us a nice break between ideating and implementing. Luckily there was no food coma…
What I learned
As a participant:
Sometimes, an idea seems simple because it’s stuck in your head. Fleshing out what it requires can help you properly assess whether it’s a good one for you at a particular point in time, with your current resources
The clarity you have about what you’re building impacts your building. It can make your experience targeted and focused, or confused and hacky. It’s better to have clarity about a smaller MVP, than to have a vague idea of a very ambitious product
Sometimes two heads are better than one. If I had built this alone, I would have built an individual version of the product because my experience of the problem is more individual. My teammate’s experience brought the group perspective, and both our ideas combined to make an interesting product!
Trust matters a lot. When you’re building with someone, you need to trust their ability to get their job done. You also need agreed-upon decision making frameworks for when there are conflicting views
As an organiser:
Small, high-intent, high-trust, and high-skill groups can achieve a lot when you empower and connect them. Facilitating this Build Session was rather easy, and I think it was partly due to the fact that we had built trust with each other over the past CWT sessions
You need to get people excited to build, especially if they haven’t built together before. Having the CWT session on Wednesday gave us an opportunity to be excited together and hype up our energy ahead of the day. This made us look forward to Saturday
Finally, I had many assumptions when planning this Build Session. I ended up having to be flexible in two ways:
I started out with a rigid timeline for the day but soon realised that I needed to flex the times a bit to allow people get in the zone. This taught me that the schedule is for the people, not vice-versa
I originally wanted people to give their demo with slides (this was probably the banker in me). After hours of building, I realised a better way to show what we’d built was to just use it and talk about it. This meant we could focus on building the demo flow, instead of worrying about getting slides ready
Next Steps
This first Build Session was another step in the journey of bringing ambitious technologists together to create tangible impact.
Later this summer, we’ll have our first Conversations with Technologists Demo day, here in London. This will be for the wider Pivotech community to see what we built during the Build Session, and the traction we’ve made so far. You’ll also get to connect with other builders and technologists. You can request for an invite here.
I genuinely hope to see you there.
Speak soon and all the best,
Nkechi
🧠 Complementary Reading
If you’d like to read (or listen to) what we discussed at the last CWT:
We're all thinking about AI
1 night. 10 technologists. 3 presentations. Somehow, all we could talk about was AI.
If you’d like to see what sparked my realisation about AI changing our role as builders:
From Executor to Orchestrator: My Journey Building with AI Agents
"The pattern is becoming clear once again: the technology doesn't replace the skill, it elevates it to a higher level of abstraction." - Danilo Alonso