I’m Kubomi, an iOS engineer at Merpay, Inc.
This article is the 10th entry in Merpay & Mercoin Tech Openness Month 2026.
Generative AI has made it easier for engineers to build prototypes quickly. Recently, I tried building a working prototype before the kickoff meeting for a small project. This made decision-making much faster. I call this approach "Build First, Discuss Later."
In this article, I’ll share how I used this approach in practice and how it changed my mindset as an engineer.
A common development flow—and where it slows down
In our usual workflow, we make sure everyone is aligned before we start building. The product manager (PdM) first creates a rough product spec. Then we hold a kickoff meeting to discuss the details. After some discussion, the PdM finalizes the spec, and engineers estimate the work and start implementation.
However, questions about details often come up even after the PdM finalizes the spec and we start building. When something like this happens, we may need to follow up with the PdM or set up another meeting. This creates more back-and-forth communication.
The "Build First, Discuss Later" approach
That is why I tried the "Build First, Discuss Later" approach. In the traditional flow, we first discuss the spec and build afterward. With "Build First, Discuss Later," we do the opposite. We build a working prototype before the spec is finalized, and use it as the starting point for the meeting. When there’s a prototype that stakeholders can try themselves, alignment becomes much easier than when we only talk through a written spec.
This approach works best for small projects or features whose prototypes can be built in a few hours or a day. For projects of that size, building first is much faster than waiting for the spec to be finalized. If the implementation is expected to take several days, a change in direction could create too much rework on the prototype.
Three steps for bringing a prototype into a meeting
I use "Build First, Discuss Later" in three stages: before, during, and after the meeting. As an example, I will use a small project where I added a single banner to an app screen. At each stage, I focused on a different goal.
Before the meeting: build the best version you can
Before the meeting, I worked with an AI to read the available documents, such as project plans and specs. I did this to help myself understand the "why" and the "what" in my own words. At this stage, the most important thing is not to make a perfect implementation. It is to make the uncertainty visible. Many details are still unclear at this point, but I didn’t stop to ask every question. Instead, I built the best version I could, based on my understanding at the time. I also wrote down the questions I had and brought them to the kickoff meeting as agenda items.
For example, in the banner project, I considered two implementation plans: building a minimum viable version for the release, or making the implementation reusable for future work. To keep the meeting discussion concrete, I built a working prototype of the minimum viable version. The UI design was not ready yet, so I used existing UI components to create a temporary look and make the overall flow work.
During the meeting: resolve open questions while looking at the working prototype
During the meeting, I used the working prototype as a shared reference. First, I showed how it worked. Then, we went through the open questions one by one. When there were multiple possible directions that we could take, I was able to show each option and explain which one I recommended and why.
In the banner example, I showed the minimum viable product plan for the release, as well as another plan that considered future reuse. Because we could compare both plans against the schedule, the PdM was able to choose the first plan on the spot. The smaller details also fell into place quickly as we looked at the prototype together. Since we already had the information we needed to make decisions, the discussion moved forward quickly.
After the meeting: reflect the decisions immediately
After the meeting, I finalized the spec based on the decisions and corrected any minor changes that we decided on. At that point, the feature was almost ready for quality assurance (QA) testing and release. Because we had already confirmed the main direction with the prototype, large rewrites were unlikely. Right after the kickoff meeting, the release already felt within reach. In the banner example, the designer took my temporary design and refined it into the final design, and the implementation only needed small adjustments.
Three things that changed with "Build First, Discuss Later"
This approach changed how our meetings work and how we communicate with the PdM. Three changes were especially clear.
First, we now often finish most of the necessary discussions in a single meeting. In the best case, the spec and implementation are almost finalized by the end of the kickoff meeting. This means we sometimes do not even need a formal development estimate. Follow-up communication after the meeting is also drastically reduced.
Second, discussions are now faster and clearer. With a working prototype, we can point to the screen and ask, "Is this behavior correct?" This helps us avoid misunderstandings that can happen when we describe features only verbally.
Third, the PdM now has less work to do. I bring concrete specification proposals to the meeting, so the PdM only needs to confirm the direction. This is especially valuable when the PdM is handling multiple projects. Reducing the time spent on communication makes a big difference.
How building first changed my mindset
These changes did more than speed up development and communication. They also changed my own mindset as a software engineer.
In the past, I thought my job as an engineer was to implement requirements after the PdM had defined them. But since I started building a working version based on the PdM’s vague "why" and "what," I have been able to join discussions with a concrete set of questions and proposals. For example, I was able to question whether a feature was needed, or suggest alternative approaches that could bring more value to customers.
I was no longer just waiting for specifications. I could help define the requirements and shape the specification.
By actually going through prototype development, I became the person with the most knowledge about the feature, and I felt more ownership of the features I was responsible for. My ideas became part of the spec, and the working prototype helped shape the product direction. Being involved in that process made product development much more fun than before.
Generative AI has made it easier to simply try building something first. In turn, engineers can now join discussions about product direction much earlier. Bringing a prototype to a meeting does more than speed up development. It can also help engineers take a more active role in product development.
Conclusion
"Build First, Discuss Later" means building a working prototype first and then using it to discuss the details. If you feel stuck because the specifications are not ready yet, or if vague specifications are causing rework, try bringing a prototype to the meeting. It can help discussions move forward and make product development more engaging—and more fun.
The next article is by Mewuto. Stay tuned!
