Founder-Led Prototyping

I’ve been involved in a few projects this year that are revealing a new way of working with clients to build applications. The new paradigm involves founders and domain experts utilizing LLM tools to create highly functional prototypes without the need for involving design and engineering specialists (at least not at the beginning). For lack of a better term, I’ll call this “founder-led prototyping”.

The old way

Traditionally the prototyping process involves technical people working from requirements docs and potentially from early design mockups to create a clickable, imagineered semblance of an application. The people creating the prototypes are generally developers who can code a rough application or designer power-users turning to prototyping tools in something like Figma.

In the traditional prototyping process, there might be a lot of time put toward creating a requirements doc and having discussions with the prototyping team (design and dev) to convey all of the details that need to be considered in the prototype. For a complicated application, these discussions could last for months.

Today’s LLM-driven prototyping tools have turned this process on its head.

The new way

Now company founders and others with an idea but little technical experience can prototype websites, applications and just about any other digital asset by simply chatting with an LLM. I’ve seen firsthand how business leaders with deep domain expertise are working with ChatGPT, Claude and custom third-party agents to transform their vision into feature-rich prototypes.

In one case, a founder I work with has put a large amount of time into a single prototype and created a fully-featured, clickable, stateful application with over a hundred pages. A formal requirements doc was never written. And it turns out it didn’t need to be… the prototype IS the requirements doc. This founder is essentially building a live, clickable, real-time requirements doc one prompt at a time.

As lead developer and designer on the project, this approach has been incredibly helpful to me. There is more information in the prototype than could be conveyed in a 200-page requirements doc and dozens of meetings (which would have been the traditional way). The communication gap between the C-suite and the development team has been significantly narrowed and less information is lost in a game of telephone between the founder, stakeholders and build team.

The role of the design and technical team

In this new way of working, the job of the app-building team is to refine the founder-led prototype and orchestrate the leap from LLM artifact to real life application. In the example I referenced above, the prototype that the client built is filled with great information and proposed user flows, but the design doesn’t look professional and the usability stinks. In this case we’re going through a second design-focused prototyping process in Figma that distills the user interface and takes a complicated UI jumble and turns it into something that an average person (or at least an average person in the industry) will love to use. Once that is complete, we’ll begin converting the prototype into a real application.

A comparison of application development lifecycles

Here is a diagram of a typical application development lifecycle comparing a traditional approach with one that uses founder-led prototyping:

There are a few differences to note here that founder-led prototyping brings to the table:

• On the front end, the time needed for documentation and meetings is greatly shortened. The founder jumps into the prototyping process quickly following discovery.
• The founder-led prototyping can take a while for a complex application, but the time needed for UX design, builder-led prototyping and graphic design is shortened. This is because of the difference in the richness of information between the founder-led prototype versus the documentation/discussion utilized in a traditional process. One could say that a prototype is worth a thousand words.
• Development time may also be shortened depending on how much of the code in the founder-led prototype is usable.
• The order of UX design, builder-led prototyping and graphic design can vary. Often times UX design and prototyping happens simultaneously. Graphic design can happen either before or after builder-led prototyping, but after UX design. For applications, I prefer nailing down a prototype before getting a graphic designer involved.

The Downsides

While overall I love this founder-led approach, there are some pitfalls. Founders aren’t UX experts and many of the layouts and user flows they come up with might be inefficient or downright incomprehensible. Sometimes founders will get attached to parts of their creation that need to change and there may be a battle to make that happen. Builders may need to fight for a design budget when a founder wants to go straight to development with a poorly designed prototype.

The founder-led prototype generally should not be considered the final prototype; it should be thought of more as a replacement (albeit a superior one) for a traditional requirements doc.