Live data from Hacker News

Ask HN: What would be your stack if you are building an MVP today?

news.ycombinator.com

171–180 of 736 posts

Re: Ask HN: What would be your stack if you are building an MVP today?

#171
* Whatever you already know

* And has good IDE support for opinionated formatting

* And doesn't require a ton of setup-to-build effort (ie, no debugging your build tools)

* And has a quick pipeline from local development to production

That's it. Language, database, framework, it doesn't matter as long as you meet those four criteria.

Re: Ask HN: What would be your stack if you are building an MVP today?

#172
Definitely old schools. I am building a MVP right now(kinda building my parachute while jumping off the plane)and I went with Django. And here is why. 1. Very vibrant community of devs and time-tested open-source libraries.If you want a multi-tenancy there is a library for that. IF you want stripe integration there is one for that. If you want "fully built out" services, then we have a plethora of free and paid templates. There are folks here(HN User rlawson)who have built many side projects using Django that they have monitized. if that monetization is your goal, then time is money and Django is your friend. 2. Very easy to deploy. This is a Major major requirement for someone like me(dabbling in webdev). Even after the demise of Heroku hobby dynos, there are things like Railway.app which lets you git deploy app, try it out and then scale it if you want. 3. Lastly, Javascript not necessary- I am a "hobby python dev". I don't have the inclination nor the time to learn yet another Javascript framework. I have an idea, know a bit of Python and I want to iterate it on my idea fast and get to the customer ASAP. Meaning, I can deploy a MVP without having to dabble with JS while jumping through all the different web pack configurations. A big win for me. So, "boring stack" definitely.

Re: Ask HN: What would be your stack if you are building an MVP today?

#173

I would use a full stack framework so I do not have the overhead of creating API endpoints. I would use Laravel with Livewire.

You might also want to check out https://wasp-lang.dev/ - it lets you use React & Node.js (although it seems you prefer php), but you don't have to write API endpoints + everything works out-of-the-box (disclaimer: I'm one of the main contributors to the project)

Thank you for your reply matijash!

I am not tied to a language. wasp looks very cool and will definitely try it out on the next educational day at the office!

Re: Ask HN: What would be your stack if you are building an MVP today?

#174
React + Apollo GraphQL (on Node) + Mongodb (with Mongoose, possibly hosted on Atlas)

The reason is simple: I'm most comfortable and proficient with this stack and it's scalable enough to run a mid-sized app. Moreover it's very easy to share the code base between web app and mobile app based on expo (React native) if needed.

Re: Ask HN: What would be your stack if you are building an MVP today?

#175
post #142
post #109

Earlier quoted context omitted.

IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference. Also IMHO, a flexible type system like Typescript makes development faster than without it…

>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.

>Simply not true.

It's not true that I think it hurts more than it helps?

Re: Ask HN: What would be your stack if you are building an MVP today?

#177

- Server: Node.js + SQLite I know JS very well, so writing HTTP handlers is quite fast. Node runs on V8, which is probably the fastest runtime for dynamic code. SQLite makes development easier as it’s just a file, gives you ACID. - Frontend: React/Mobx/Tailwind SPA hosted on firebase hosting. I think the concept of JSX (write your HTML with JS) is good as it gives you a real language instead of a restricted templatin…

What do you use for auth?

Re: Ask HN: What would be your stack if you are building an MVP today?

#178
I went through this exercise recently, looking for a stack for a greenfield project which I had full control over. Tl;dr: I chose Rails, albeit with ViewComponents.

When I compared the existing frontend backend stacks like Svelt, Next, or a Go, Rust, whatever backend + React frontend, the amount that’s in Rails out of the box is just not even close to the rest. From ActiveRecord to secret management, a dynamic ecosystem of gems for almost anything and much more, choosing another stack just didn’t make sense.

Believe me when I say I really wanted to choose React for frontend because of its community and ecosystem but for an app with a backend that there is so much Rail does for you that you’d be spending weeks rebuilding with anything else.

A caveat is that this is Rails + Hotwire and Turbo + ViewComponents that makes it a no brainier. The old school Rails MVC would have been a harder sell

Re: Ask HN: What would be your stack if you are building an MVP today?

#180
I used to be into CakePHP and then Laravel, I liked the monolith style architecture where the template, API, and user interface all live together.

I've done backend separated from frontend and while its nice it can be a pain to manage on your own, which is usually what your doing at MVP time.

Now I'm more focused on using stuff like Strapi or rolling my own Hapijs server when needed and having a JAMstack frontend to interact with it.

Next.js has been a breath of fresh air to bridge the conceptual gap between what I was doing in Laravel (PHP) and now im doing in Next.

JAMStack and serverless functions are awesome because you don't need to maintain servers anymore. Most sites can be primarily static especially when you are prototyping... the data that comes from an API can be mocked for demos.

SQLite for DB development without the internet. Being able to run tests or do other stuff thats DB destructive without connecting to anything. No local server, no nothing. Just you and your flat file. Bliss.

Post reply on HN