How to build a prototype
When you are deep in the weeds on some topic, you’ll generate many ideas. Prototyping is excellent for quickly verifying these ideas so you can either discard them or spend more time on them if the feedback was positive.
At Tokenomics DAO we’ve been doing this a lot. We’ve built an Evaluation Framework, the Tokenomics Design Framework, a custom voting tool, and Tokenomics Hub.
I want to take the most recent prototype — Tokenomics Hub — and walk through how I’ve taken it to a working prototype, almost MVP in a couple of weeks using JavaScript.
TL;DR
- Copy, paste, adjust: Find something similar and use it as a template. No need to reinvent the wheel.
- Use momentum: Get stuff done a lot faster when you’re in the flow and are ticking a lot of boxes. Think in small steps to keep that dopamine from your achievements coming.
- Build chunk by chunk: Along the same lines as #2; have the end product in mind, but don’t let that overwhelm you. Build small, working iterations that you can show and use.
- Copy and paste styles: Leverage building blocks, such as ready-made and styled components to build stuff faster.
- Simple first, best solution later: It’s tempting to nerd out and dive into some topic, but try and go for speed and simplicity first. You can always build the proper solution later.
Prototype vs. MVP
Our friend ChatGPT defines it as follows:
I’m not too fussed about definitions here and think there is a connection where one can move from prototype to MVP easily, sometimes without notice. We do that all the time.
The most important thing for both however is to use incremental steps when building, so that a user always has something to try.
The idea of Tokenomics Hub
The idea we want to verify is a platform, where users can design, discuss, research, and share all things tokenomics.
It’s essential to have the end product in mind.
More important is to start with something small and tangible.
A fraction of the end product.
For us, it’s a list of protocols and a breakdown of their respective tokenomics. Starting with a small and tangible first version makes it easy to utilize templates.
Many templates exist, so I picked a blog post example on Nextjs using Prisma with Planetscale and deployed it all on Vercel.
Here is what I used: https://vercel.com/guides/nextjs-prisma-postgres
The template shows you how to build this.
It contains most of the framework to take it to this:
Copy, paste, and adjust
I like to use this approach to spin up something quickly, validate your ideas, and continue to add features as I see fit.
I’m not a great developer by any means, but a little JavaScript and some CSS will get you quite far if you have the right template to start from.
Building a prototype mostly is just copying and pasting different elements, filling them with your data, and styling them so they look like your own.
There are a ton of different sources to get you started such as this repository from Vercel — just clone the template you like, install it, run it locally, make your changes, deploy it and most importantly, validate it.
Use momentum
This is where the image from the beginning comes in again:
Building stuff can often be a mind game, where you might feel held back by the overwhelming complexity of the task. That’s why it’s so good to copy, paste, and adjust.
It gets the momentum going. All changes you are doing now are building on something that is already working and showable.
You’re not starting from a blank slate anymore.
I find it a lot easier to add new bits and pieces, modify or extend and dare to even take on larger developments from here.
Often I won’t even start with a prototype if I have all these complex features in mind.
It sort of blocks you. You think you can’t pull it off and you don’t even start.
I try to think small.
In small steps at least.
You should have the big picture in mind but don’t try to build that immediately.
It’s important to have these little milestones of working and showable prototype versions.
Building chunk by chunk
I would have thought it was way too difficult to build a custom form, with a rich text editor, image upload, and autosave, but I broke it down into small achievable chunks.
Initially, the app didn’t even have data entry, keeping it as simple as possible. Once I had that first chunk up and running, I took on the next bit i.e. building a custom form with Formik, that is synced to our DB.
✅ Done, Deployed, Achievement unlocked.
Once the custom form was running, I managed to find the rich text editor TipTap and got their example to work, and added it to the form.
✅ Done, deployed, another achievement unlocked.
Generally, I find it more important to release something that’s working, than to ship the perfect product all at once.
Don’t get intimidated or scared by the complexity of the end product.
Just take it piece by piece and make sure to have these little achievements aka working or stable prototype versions in between, that you can show.
Copy and paste styling
I like to leave styling for last and ideally to a pro. Nevertheless, I found that tailwind is a great and easy-to-use library to style your app.
What I like best is the countless examples and templates that are available and can be easily copied and pasted into your app.
Building a prototype is a lot of copy and paste.
Nice header bar. Looks familiar?
That’s because you can just copy the styled code and adjust it to your needs. Don’t need to be a pro in CSS.
For many other areas, I’ve done just the same. Just google tailwind style table and you’ll find a whole stack of sites like this one with a ton of examples on how to style nice tables:
Styling doesn’t need to be perfect for prototypes, but if you want people to try stuff out, it shouldn’t look too bad.
Simple first, best solution later
When building a prototype, I first like to go for speed. You don’t need the best solution with all the bells and whistles from the start. What matters is adding features that let you validate your idea.
For most, an intimidating topic to tackle is the user-login-flow. Think of signup, social login, roles, etc. 🤯
I started with a more technical solution, using next-auth, but it quickly got a little too complicated.
It was slowing me down.
I discovered Clerk, which takes care of all the heavy lifting and allows me to implement the whole user flow quickly.
Who knows if it’s the best solution, but it got me a quick win with my user flow. The library is quite slow but the team has promised to ship a fix for this soon.
Once it’s time to mature and find a better solution you can still ditch the simple initial one.
I’m willing to take that sacrifice. What’s the alternative? Building everything properly from the beginning is probably going to take you a lot longer.
A prototype is all about getting something out quickly and validating it with users.
The initial library I used for the calculator was really simple and quick to implement, but I was starting to reach its limits (too bulky, slow, and not flexible).
I found better ones, namely VISX from Airbnb, and replaced chartjs. It did take more time to build it properly, but since the rest of the app was already in place, it made it a lot easier to implement and fit in.
Conclusion
This was very focused on developing stuff, but the topics mentioned are very much applicable to non-coding examples like the Tokenomics Design Framework too.
Here are the key takeaways:
- Copy, paste, adjust: Find something similar and use it as a template. No need to reinvent the wheel.
- Use momentum: Get stuff done a lot faster when you’re in the flow and are ticking a lot of boxes. Think in small steps to keep that dopamine from your achievements coming.
- Build chunk by chunk: Along the same lines as #2; have the end product in mind, but don’t let that overwhelm you. Build small, working iterations that you can show and use.
- Copy and paste styles: Leverage building blocks, such as ready-made and styled components to build stuff faster.
- Simple first, best solution later: It’s tempting to nerd out and dive deep into the weeds on some topic, but try and go for speed and simplicity first. You can always build the proper solution later.
Everyone will have their preference and the way I like to do stuff is often quite pragmatic, but to build prototypes and even MVPs, it might be the right mindset to have.
