(I'm non-technical) What is the best back end framework to use for my web app?
16 comments
The "best" is the that the team you hire is most familiar with and recommends. Seriously, any framework can do any of this, and your constraints aren't really constraints, it's a wish list that essentially anyone building an app has.
So, the good news is you can ignore the framework. Instead, focus on finding a company that:
* does what they'll say they do during your initial conversations and scoping. If they say they'll email X by Y (like a bid or a followup) and it's late or doesn't happen, move on. The pre-sales period is as good as their service will get.
* works iteratively. Look for a company that has lots of small releases (on the order of a week to a month), not a giant scope and big release/deliverable.
* ideally, has done some work with the general type of users/customers you're selling to or are using the app. I don't mean technically, I mean in terms of use cases. For example, a development consultancy that's only designed dashboards for business apps is probably not an ideal choice for a consumer-facing app. They may well be able to do it, but will be less likely to point out flaws in your thinking. Another way to put this is: ask for the URL to something similar they've created (and go try it!).
If they do those things, whatever they recommend will be better than anything you come up with. And if they don't, it doesn't matter anyway :)
Finally, if you haven't already, put together wireframes of as many screens as you can think of - even if it's with pen and paper - and show up with those. They can be terribly ugly, as long as they show what information and choices you envision on each screen and let you talk through why. That will eliminate a ton of uncertainty and effort. Google for pen paper wireframes if you aren't familiar with this.
So, the good news is you can ignore the framework. Instead, focus on finding a company that:
* does what they'll say they do during your initial conversations and scoping. If they say they'll email X by Y (like a bid or a followup) and it's late or doesn't happen, move on. The pre-sales period is as good as their service will get.
* works iteratively. Look for a company that has lots of small releases (on the order of a week to a month), not a giant scope and big release/deliverable.
* ideally, has done some work with the general type of users/customers you're selling to or are using the app. I don't mean technically, I mean in terms of use cases. For example, a development consultancy that's only designed dashboards for business apps is probably not an ideal choice for a consumer-facing app. They may well be able to do it, but will be less likely to point out flaws in your thinking. Another way to put this is: ask for the URL to something similar they've created (and go try it!).
If they do those things, whatever they recommend will be better than anything you come up with. And if they don't, it doesn't matter anyway :)
Finally, if you haven't already, put together wireframes of as many screens as you can think of - even if it's with pen and paper - and show up with those. They can be terribly ugly, as long as they show what information and choices you envision on each screen and let you talk through why. That will eliminate a ton of uncertainty and effort. Google for pen paper wireframes if you aren't familiar with this.
Thank you so much for the help troy, really appreciate it.
It's late but I hope this helps (and I hope others can chime in)
I second noahc's comment on the specific stack. But more generally, some keywords to help sort/pick through to optimize for 'framework that is very common'.
Ruby on Rails (RoR), Laravel (PHP) and Django (Python) is (I think) the most familiar and widely used. By default will tackle most of your needs and be familiar enough to have >90% problems you faced tackled by others (and solved by googling). Make sure you insist to use Relational Database to save headaches along the way (PostgreSQL/Postgre and MySQL is the two most common ones).
As you are going to a dev shop, make sure that they are sticking to at least the above constraints. By having those, you can shop around for other dev shops in case you need to expand/mismatch down the line.
For now, your focus as a founder is to get the main product off the ground, and performance is second to that. It's a "good problem to have" and hopefully you'll have enough resources with the product success to improve it. Generally you can throw money at scale as long as you are not as big as 100k MAU, by throwing in more server/bigger servers.
For the specific dev shop, troy's comment is great to pick one. But for the framework, I recommend leaning to the ones I mentioned.
I second noahc's comment on the specific stack. But more generally, some keywords to help sort/pick through to optimize for 'framework that is very common'.
Ruby on Rails (RoR), Laravel (PHP) and Django (Python) is (I think) the most familiar and widely used. By default will tackle most of your needs and be familiar enough to have >90% problems you faced tackled by others (and solved by googling). Make sure you insist to use Relational Database to save headaches along the way (PostgreSQL/Postgre and MySQL is the two most common ones).
As you are going to a dev shop, make sure that they are sticking to at least the above constraints. By having those, you can shop around for other dev shops in case you need to expand/mismatch down the line.
For now, your focus as a founder is to get the main product off the ground, and performance is second to that. It's a "good problem to have" and hopefully you'll have enough resources with the product success to improve it. Generally you can throw money at scale as long as you are not as big as 100k MAU, by throwing in more server/bigger servers.
For the specific dev shop, troy's comment is great to pick one. But for the framework, I recommend leaning to the ones I mentioned.
Thank you very much for the help!
Welcome. I've been involved in this position before (came in as a PM/Tech in a startup which outsourced the development). It went well, but would be easier if the vendor were to stick with those requirements to ease maintenance/feature development down the road.
I think this question is a much bigger than it seems at first. I made a streaming website a while ago, depending on how non-technical you are I open sourced it if you want to browse, it's not well documented, but it should give you a sense of all the pieces needed
https://github.com/MichaelEstes/Scrim-TV
I used Go as the backend because I knew it well, but you're also going to need a few databases and a CDN. It's a lot of moving parts without a black and white answer.
Depending on how non-technical you are, I'd focus more on finding the services that meet your product needs for the best price. Moving to a new backend is a lot easier than moving to a new cloud service provider in my experience. There's only a handful of them out there so once you have that it won't be hard to find a shop that has a great deal of experience in it and they'll use the backend they have the most experience in.
Depending on how non-technical you are, I'd focus more on finding the services that meet your product needs for the best price. Moving to a new backend is a lot easier than moving to a new cloud service provider in my experience. There's only a handful of them out there so once you have that it won't be hard to find a shop that has a great deal of experience in it and they'll use the backend they have the most experience in.
Thank you for the response much appreciated !
Happy to offer consulting on this for a few hours. Add your email to your profile and reply to this comment and I'll get in touch.
I have my email attached but here it is - [email protected]
[deleted]
You could do a lot worse than to choose Ruby on Rails.
Laravel
The more you know about dev the harder it is to choose a dev or stack, so don't feel bad
...adding, based on other comments, Balsamic is your friend.
The more you know about dev the harder it is to choose a dev or stack, so don't feel bad
...adding, based on other comments, Balsamic is your friend.
Are you saying that Laravel is the best in terms of others developers being able to pick up where someone left off?
I did not intend to say that but I would say that
...adding, more exactingly, that php/laravel is _so_ popular and they are each so accessible that they should really be your first choice -- unless you have some compelling reason to go in a different direction. If you get to the point where you have funding, then your hired techie can worry about how to grow the tech. Adding, starting with one stack does not confine you to that stack. For instance, your web stuff can be in php/laravel, and your back end processing jobs/crons/queues/scheduled tasks can be in python, or hosted as js/node lambdas at aws, etc. Would be common. God knows what tech you will use to build your mobile apps -- about the only thing anyone could reasonably promise you there is that it _will_ be a disaster and it _will_ be the wrong choice no matter what choice you make there. So just start talking to people, documenting, probing, dealmaking, marketing, distributing, and building. Imo.
I misspelled Balsamiq too
Laravel is not perfect
For instance, their new version 8 massively complicated the entire ecosystem in myriad ways
But its still probably the safest best option
A big part of my decision would be if there is an existing saas/boilerplate/plumbing 'framework' available for the chosen platform
I'm confident in two or more
A couple/few related to php/laravel, and saaspegasus for python/django
I think there are certain truisms about this part of your journey
(Admitting I have zero basis to be listened to other than years of learning how not to do things, years of reading and listening to startup articles/pods, etc.)
Make a decision and move
There is no right answer
There is hardly a wrong answer
Do all the things that startup people say they will but still do not -- like stick to the M in MVP and not chase features without talking to paying users, don't write the native apps unless/until you truly need them (they are so much gd work), etc.
...adding, more exactingly, that php/laravel is _so_ popular and they are each so accessible that they should really be your first choice -- unless you have some compelling reason to go in a different direction. If you get to the point where you have funding, then your hired techie can worry about how to grow the tech. Adding, starting with one stack does not confine you to that stack. For instance, your web stuff can be in php/laravel, and your back end processing jobs/crons/queues/scheduled tasks can be in python, or hosted as js/node lambdas at aws, etc. Would be common. God knows what tech you will use to build your mobile apps -- about the only thing anyone could reasonably promise you there is that it _will_ be a disaster and it _will_ be the wrong choice no matter what choice you make there. So just start talking to people, documenting, probing, dealmaking, marketing, distributing, and building. Imo.
I misspelled Balsamiq too
Laravel is not perfect
For instance, their new version 8 massively complicated the entire ecosystem in myriad ways
But its still probably the safest best option
A big part of my decision would be if there is an existing saas/boilerplate/plumbing 'framework' available for the chosen platform
I'm confident in two or more
A couple/few related to php/laravel, and saaspegasus for python/django
I think there are certain truisms about this part of your journey
(Admitting I have zero basis to be listened to other than years of learning how not to do things, years of reading and listening to startup articles/pods, etc.)
Make a decision and move
There is no right answer
There is hardly a wrong answer
Do all the things that startup people say they will but still do not -- like stick to the M in MVP and not chase features without talking to paying users, don't write the native apps unless/until you truly need them (they are so much gd work), etc.
Thank you so much for the thoughtful explanation. Honestly from what I can tell, Laravel is the most popular with remote devs and dev shops. So I think I will end up going with that for now.
node.js which uses javascript
The developer can then use Javascript both on the backend and on the frontend.
So I am non technical founder. I am searching for dev shops to help me build a web app. I want to make sure I choose a dev shop that uses that right backend frame work, that is in line with my vision for the product.
1.) The Product (Generally) - An online discovery network. User profiles, ability to chat with users. Ability to live stream. Ability to create community groups where many people can interact and chat. Payment integration etc. Filter and search for different users by category. Very feature rich...
2.) I want to make sure it's a backend framework that is very common and lots of programmers are familiar with. When I am recruiting I want to make sure this the right backend tech stack that is current and relevant and lots of people work with.
3.) Want to make sure it is right for scale and for lots of users.
Thanks in advance! Been tricky navigating developers since I am non technical, trying to make the right decisions before I go with someone :)