How important is the frontend for a MVP?
Hi everyone,
I'm building a backend/data heavy app. The data is available. For the frontend, I've created a simple mockup to collect some ideas.
Now, thinking about a MVP, I need a GUI.
As the GUI is quite important for the first impression, I would like to gather some opinions.
I can think of three alternatives:
- Django backend that serves "static" HTML-files (for example I could use the Datta Able boilerplate)
- JavaScript frontend framework (React?) with API backend (I would have to loose my React-virginity)
- No Code with no code API connector + API backend
The app is basically a reporting dashboard for which I could implement the frontend with Django & the Datta Able boilerplate (based on my available skills, that would be the fastest option).
But, that will lack some "magic".
Thinking of a MVP: What do you think, how important is a 'fancy' frontend?
Hm, additionally, most user feedback I ever came across was about the GUI. So, potentially, I would have to ramp up something smart later down the road anyway ..
WDYT?
I like Ash Marya concept of having an offer vs. an MVP that tends to take way longer than anticipated for most people.
Is it this one here: https://blog.leanstack.com/dont-start-with-an-mvp/ ?
It was an interesting read. I think more people here in this community should know about this blog.
It depends on the market and the product, and you'll have to use your judgement.
I'm looking at a recent post of yours, where you describe three different product ideas: https://www.indiehackers.com/post/when-to-scrap-an-idea-6ecad55336
I know you're not necessarily building any of those exact products now, but I think they make good examples regardless.
If you're building Idea #1 (long-term travel log), I think front-end may matter a lot. You'd be mostly trying to get a consumer audience to adopt a new behavior to solve a problem they may not already think they have. This is hard! I think a slick front-end could give you a better chance.
If you're building Idea #2 (stock sentiment analyzer), I think it's almost the opposite. You're selling to people who will only care if your tool makes them more money. (It's almost like B2B in that way, but not exactly.). These people know what their problem is, and many of them are already trying other solutions. You win them over by delivering value, which comes from whether your insights help them make better trades. You could just manually send them smiley faces by SMS or email if it got the job done. No one's going to complain if you're helping them make money.
If you're building Idea #3 (easy ad & landing page builder), I think it's somewhere in between. Here you do have a B2B market, where the customer may well know what problem they have. So, the good news is that early users should be satisfied with an unpolished experience as long as you are helping them achieve their objectives. However, it seems like the value you plan to deliver is ease-of-use, which may be tough to deliver on without a well-built front-end.
woooooosh @mattgillooly where can I buy you a coffee???
The analogy to a car would be (to simplify what you are saying for future internet researchers):
When car manufacturers create a new car, they can do both (engine & car body) at the same time, because they have big teams. But I'm only one person, so I focus on the engine for now (and take any car body that is available to me). If the engine can deliver what I want it to, then I can invest time into the design 😎
I don't know how car manufacturers think about these things, but if the car analogy is helpful, I would have thought of it more like:
Idea #1: commuter car
Idea #2: tractor
Idea #3: pickup truck
The commuter car is a pure money loser. Ultimately people choose whatever they feel best about. Or maybe they take the bus instead.
You need the tractor for your farm to make money. A better one might make you more money, and you can make the decision on a spreadsheet. You'll take the ugly one if it makes for the best bottom line.
You can do a lot of different things with a pickup truck. If you're a contractor, it's probably vital to your day-to-day business. But some people just use them to get around, and could use a bicycle instead. You ultimately appeal to both emotion and logic when selling this, because buyers are split on their motivations.
@mattgillooly nice analogy. I agree:)))
There's another architecture you can have - you can serve Django app which also renders the ReactJS script and app (including the initial data for the app), allowing for as much additional magic as you need, without having to go deep on a static front end and API backend. Let me know if you need help (noting that I use VueJS, not ReactJS).
What would be common keywords to search for the architecture you described?
'Unorthodox' ... ?
Just kidding - I have no idea what it's called.
But it's not hard to do. What you're doing is creating a normal Django static app except that in your Django template you're also:
So your Django backend serves the HTML. The browser loads that HTML, including the ReactJS script from the CDN. Then the browser loads your React app, using the data statically rendered into the HTML by Django. Hey Presto - a React app on a Django backend.
Note that the ReactJS is a full app - it can even make XHR calls to your (other) Django endpoints without leaving the page. So you can still have a frontend/backend paradigm, it's just the the frontend is being served by one of your Django endpoints (not a static JS app on a separate host).
It also does well with SEO because the initial data is rendered with the page.
So for a mostly static app, it's an easy way to add a little magic.
Does that make sense?
Yeah makes sense. Django can be used as a solution to serve a website. And, it is true that it is not necessary to host a JS framework seperately only to profit from the functionality the framework offers.
SockPuppet (mentioned somewhere here; StimulusReflex is the Ruby-equivilant) has a similar approach that you described. Serve HTML + reactive JS from Django. Then, instead of send always "full" requests from Website to Django, SockPuppet allows to send only the "reactive part" to Django instead. Then, Django processes the data and sends it back to the website where JS is waiting for the response to update the "reactive part".
People absolutely judge books by the cover. We are strongly biased to assume that high production values is an indication of quality. When users see sites that look half-baked, they are not thinking "oh, this was created by a pragmatist who is smart enough to test a concept before investing a lot of effort in making it look like something I'd even remotely consider using".
What's worse is that first impressions really matter. If you think it's hard to get them to come check out what you've done, just try getting them to come back.
You've received a lot of specifc technical advice. The only tech stack you should be using is one you're already familiar with. Otherwise you will get completely sucked into bike shedding and learning cool tools you might not even end up using instead of building what you really need.
In particular, I strongly advise you to ignore the suggestion that your app should be an SPA. Your MVP probably doesn't need to be an SPA, and that's because most applications in general don't need to be SPAs. The only people who believe that all apps should be SPAs are people who don't know how to build good sites that aren't SPAs.
If you're using Django, you can get all of the benefits of an SPA by using a library like SockPuppet. The idea is to keep your application state on the client, and push changes to the client over WebSockets. It works incredibly well, and you don't need an SPA framework or a JSON API to make it work.
hi @leastbad thanks for your input.
In regard to "quality of frontend has impact on perception of product quality", I agree with that point. I think that was my initial motivation to write this post.
With the input of this thread here, I have decided onto the following strategy:
Also, many thanks for the tipp about sockpuppet. It seems to solve my exact problem. I will look into the effort it would take to implement a reactive frontend with this technology.
Depends on how many pages.
If it is only a few pages buy https://tailwindui.com/ use Vuejs (very easy to learn) and look into https://supabase.io/ (hosting a backend is a huge pain)
If you plan on creating 10+ pages of very detailed charts/tables look into React (you can always reuse a lot of the Vue code).
I was a Django lover but the tools have advanced so much and customers expect fast and flexible UIs.
Thanks for the two recommendations. The Datta Able boilerplate uses bootstrap. So it is not completely out of fashion (I hope).
It is more like, when I serve through Django, then every page is reloaded and I don't have this SPA-feel. But the overall opinion here is that "form follows function" and that resonates with my gut feeling. So I'm happy to ditch a 'fancy GUI' for now.
I use to think the same, but the bar for products has risen a lot. It actually isn't any harder to build a SPA.
You might need to learn (but you would need to anyways), you should be able to move faster with SPA as well.
Customers want a product that looks nice, works and improves often.
What you are saying hits well.
In case the app hits a sweet spot, a modern GUI is indispensable. The first impression is just too important. So, it is not something that should be avoided forever ("you would need to anyways").
Thinking about this, I will spend a bit to answer myself the question if it is worth to invest now in an architecture that would allow me to exchange how the frontend is served. Thanks.
honestly, whatever is going to be the fastest.. to get your product in front of a real user. so, choose that path. you can always make it "prettier" later... but, nothing beats actual value.
Thanks for the input. When I launch the alpha, I think I have to find out if the interested person is looking for value. Some people are turned off by a product when the GUI doesn't hit a certain level of interactivity or it doesn't invite "to play around".
perhaps your copy needs work then too?
... sometimes it's how we talk about it that confuses people.
Agree 100%
The first yahoo, first google, first facebook, first amazon, first graigslist, first windows, first apple...... ahhhhh, well, whatever..... Guess what I'm going to say. (Fancy front-end means you're not going to be a unicorn 😂🤦♂️)
Value doesn't hide in fancy graphics, value is value.
Yes, that is very true what you are saying here. I can ignore an interactive GUI for now.
Probably less important if B2B, more important if B2C. What is your product?
Hi - that's a good question. I didn't think about that yet. So, thanks for asking 😄
I think it is B2B with a focus on the individual.
Going back to your recommendation, it would mean the GUI is not so important for now.
There's a saying that if you aren't embarrassed by how your MVP looks then you've launched too late.
If your product/service provides value, the way it looks doesn't matter. It just has to be functional so choose the option that will get you up and running as quickly as possible.
Nice saying - will there be ever a moment when it is possible to think "all done"?:)
I don't know if there is an "all done" point. Maybe when you sell? Best of luck.
my question was rhetorical😄
This comment was deleted 3 years ago.
hm, ok - When looking for alpha/beta users, I should lookout for early adaptors for which the app might be beneficial.
What do you think about the appeal of a MVP? E.g. choosing the right colours, how to address the user etc.