I'm starting with coding MVP of my idea described here : https://www.indiehackers.com/post/want-to-see-how-your-hometown-changed-over-the-last-100-years-5fbe51ebff
I was always starting with new projects from the backend, db design and simple login with user management and so on. But that approach failed for me several times, as I would build login and few CRUD tables and then stopped. It would take me too long to have anything viable so I would lose all the motivation I had.
This time I'm thinking of shifting the approach to building UI first and then connecting the backend.
What are your takes on this topic?
I lean towards front-end first despite more back-end experience.
There are some API design decisions that you will make for the front-end that you might not even think about if doing the back-end first because you would be more engrossed in pure business logic.
I start with the front end, and by that i mean figure out what you want the user to do, Draw it on paper each page/screen, buy a bootstrap template etc, I then make each page which was planned earlier using the template. So now the UI looks like how you want/need it to. Then I start making it interactive. I look at each page and see... ohh i need a form to register the user. So that means I need a user table etc etc, Then as I build that out, I see what things should be happening in the background as a user is using the product. Send an email here, set something over there etc etc. When u start putting the UI down it starts looking like a real product, Just one that doesn't work yet. Should help u with being motivated. Its also allows u to see what tables and DB things u need.
Hope that helps u.
Makes alotta sense! I'll go with this personally since I had the same problem :)
Im glad this helped you out. Sorry I made some typos. I fixed it should make more sense. I wrote that at 3 am lol.
I too start by building the frontend. Heck, I decided to only build the frontend for my project, and stick with Firebase for the backend. The reason for going frontend first is that it's already something you can share with others, and get early feedback.
Consider your users.
Ask the question: What is that MVP that your users can get value out of?
To build a solution for the answer might not even require for you to write back-end services. Or you might not even need a UI, just use it as a CLI.
It is entirely up the the project what you are currently building. Don't get the work done just so that you can get work done. Build the most valuable features first without worrying too much about the architecture and the technical details.
Here is the day 9th of my reality show about the development of SaaS application that includes backend and frontend. If you open the article you will see links to previous days where I describe in detail what exactly I'm doing. I would say my process involves all - frontend and backend - but always starts from:
Cheers!
Of course it depends on the case though, in my recent project, I started building frontend first and then connected it to Firebase backend.
It was nice as I totally skipped implementing auth part - not only simple login but also third party OAuth and the schemaless DB helped me a lot.
It required to learn for the first time, but it was worth.
In this case, my product is a note-taking and task management app ( https://tasquet.app/ , under development).
So firstly I had to focus on implementing an editor for writing experience, and in contrast, DB, auth and other server-side logics were not special. Firebase's DB and FaaS were good enough for such needs.
First of all your mindset should start with the fact that build process is iterative; so you'll return to adjust something somewhere.
Usually I start writing down what the service will offer to the user and than try to design on paper the workflow an the pages design.
Found the user operations I write the API that I need to fulfill the these operations and consequent the DB tables.
For most web apps, I start from the schemas like you. But when I use to make games, I rushed to get visible feedback as fast as possible and then built out more logic as I went and then the server component would be the very last thing.
I mean, whatever makes it feel more real from day to day. I tend to start with quite a lot of schemas and data processing because that works for me, and because I find front-end harder going. Sometimes just a lot of sketching and no code at all for a day or two. It won't look like a finished product for a long while so you have to find the wins and the continuing motivation where you can. I guess that will depend on your skill set.
But you still have to finish, whatever that looks like, and the slog will assert itself. For me that's endless fixing of forms & wonky CSS. Again I think that's probably also shaped by your skill-set, but recognising when the slog is upon you, and accepting that you have to switch gears - that's pretty crucial too after skipping through the fun parts for so long.
Frontend
I will sketch something very rough then hop in. You will learn what is possible and worth it once you start coding.
This comment was deleted 6 years ago