My tech is super no-code (as it suits my business and teaching others how to do the same!).
- Webflow: landing pages (and I actually use this for password-protected 'members' pages)
- Typeform: membership submissions (and payments)
- Stripe: payment processing
- Airtable: my database
- Zapier: to connect everything (automatic emails, paid members, sending receipts, sending new tutorials, adding to the database, etc.)
I chose this route to start off because I wanted to validate that newCo could viably make money before I committed. In my business I teach people how to build startups without code, so it aligns perfectly with my audience.
In order to get my idea off the ground and a proof of concept working, I opted to use Ruby on Rails to produce InView. I feel it's still a relevant and very powerful framework to progress quickly and easily from a basic app right through to a fully fledged SaaS product without having start again in another system.
Heroku is my application server of choice and I already had a set of tooling and deployment systems in place to streamline a TDD/BDD approach to the development process — something to bear in mind if you're about to embark on a new project. Do what comes easiest, get building, and experiment with your idea quickly in a way that you'll be comfortable managing going forward.
Place Card Me is built on a pretty standard Python/Django stack: Nginx web server, Django app, and PostgreSQL database. It's a tech stack that I already had a good amount of experience with and knew I could stand up and work in efficiently, and also one I knew would be long-term sustainable and scalable. I was very glad to have made that choice as I have been able to leverage a lot of my prior experience, knowledge and tools — and to bring learnings from Place Card Me into my other projects.
While we all love exploring new technologies, your core stack — in my opinion — is not a place to do that — especially if you're like me and enjoy building many different projects. If, instead, you are consistent with your stack across projects then you also will find consistent ways to handle all the other peripheral things that come up on every project like error monitoring (Sentry), asynchronous and scheduled tasks (Celery), and even things as simple as sending email (Mailgun). These then all come with great economies of scale. It's important to keep in mind that it's not just your web application you need to figure out, but every other peripheral service associated with that application — a list that only grows over time if you are successful.
Join the Indie Hackers Community
We're a group of founders sharing our stories and helping each other build profitable online businesses.
Our tech stack is geared towards simple, friendly-to-use tools.
The Vue style guide is another strong reason to pick this library. The Vue vs. React debate seems to be taking on steam this year. There is no "right" answer. However, I think Vue falls into the camp of people who might like Python: "There should be one — and preferably only one — obvious way to do it."
Other notable services that we like:
The tech doesn't really matter for a members-only media/content business like Page Flows, so going with a fancy new technology would have been a distraction. I just went with what I knew.
So far, I have no regrets, as I can prototype features and iterate quickly. Once the product is at the stage where it's more defined, I'll probably work to improve the user experience with a more dynamic front end.
I'd recommend sticking with what you know even if it's less fashionable, unless your priority is becoming a more employable software engineer.
Dependabot is built using Ruby on Rails, with PostgreSQL as our main datastore, Redis for caching, and React on the front end. We deploy to Heroku. As such, pretty much the whole stack is plain vanilla.
That's unashamedly by design. I had a decent amount of experience working with that stack and there wasn't a compelling business reason not to use it for Dependabot. I was more interested in getting the service working than experimenting with new technologies, so stuck to what I knew. I'd advise anyone else building a business to do the same — you'll face plenty of other challenges along the way, after all.
One interesting part of our stack is Heroku. Dependabot actually has really complicated platform requirements — every day we need to spin up thousands of isolated environments to evaluate our users' dependency files. Not only does Heroku handle that easily and quickly with its one-off dynos, the price has never been above 10% of Dependabot's revenue. It's an area I'm extremely pleased we've not yet had to innovate on.
I primarily chose this stack because I professionally develop enterprise applications using the same and wanted to get the MVP out as quickly as possible with a good foundation that I could continue to build off of. I think this is the most important consideration when selecting your technology: what do you currently know? There are many ways to solve a problem — start where you're strongest and build off of that.
This is a mature stack that has good support from Microsoft as well as the open source community on the back end, plus a full-featured Stripe library for the rent collection we do. The front-end libraries are endless. There are an abundence of .NET developers when it's time to scale up development and the Azure platform is built to scale automatically as the need arises. I want to be as hands-off as possible when the business really starts to pick up, this setup allows me that freedom.
When choosing our tech stack, we wanted to remove anything that would slow us down. Ultimately, the only thing that really matters is getting stuff built, deployed, and into the hands of customers.
For Transistor.fm we're using:
- Rails 5.2 (because it's what @jonbuda knows best)
- Postgres 9.6 (because we like the community + features)
- Hosted on AWS (because we got free credits through Stripe Atlas)
- Semantic UI design framework (because it's what Jon knows best)
Ruby on Rails has entered it's "maturity phase," which means it's no longer the "hot new thing." But that's ok with us. There are still tons of resources for Rails, it's widely supported, and it's stable.
Also, when we're ready to grow, I know dozens of talented RoR developers that we could hire. Hiring is a key element a lot of folks don't consider when they're choosing their tech stack.
On the back end it is Node.js because I had to create an API for sending emails and a couple of action buttons inside them (like getting the next task or upgrading to the full version).
My professional background is in front-end development, so it is much easier to get things out quickly when you are already good with the code syntax and best practices.
While the product is relatively small, there was a space for learning from my mistakes. What I learned is that you should definitely try your best to make the code of your MVP as simple as possible, but don't be too lazy with that. You don't want to find yourself refactoring your code the day after you wrote it just because you didn't spend half an hour researching possible use cases for your features.
Kernl at its inception was a side project to test out some new technologies. Back in 2015 Node.js was starting to get very popular and MongoDB was starting to gain maturity, so I decided to use those for Kernl's main backend technologies. In hindsight using Node.js and Mongo has helped me iterate and respond to customer needs quickly. At the time I didn't really know all that much about them and was looking to learn.
Aside from those choices I decided early on to use AngularJS 1.x for the front end. I knew that if I wanted to start and finish an MVP of Kernl I would have to be using at least some technologies that I was familiar with. Three years later the Angular code base is starting to show its age, but the effort to rewrite into something more modern isn't worth the cost.
If I were to start over today I don't think I would change anything. Kernl's use of the MEAN stack has helped lead it to success even with the non-trivial scale it operates at. For people starting a new project today, understand your goals before choosing a technology. Is your goal to learn something new? Then choose that hot new framework or language. Is your goal to build a product as quickly as possible? Maybe you should stick to whatever language or framework you are already an expert in.
For caching I also use Redis.
For email I recently started to use SendGrid.
My editor of choice is PHPStorm — a tool I couldn't live without. Using it gives me the confidence that my code is always as good as it can be. On top of that, the Xdebug integration saves so much time when debugging.
All of my plugins run on Gulp, Composer, npm, Sass, and jQuery. I've built a number of custom npm and Gulp scripts to automate a lot of my workflow, like compiling Sass, deploying plugins, updating version numbers, etc.
My stack is constantly evolving. I'm always open to try new things; I'll admit I already have my eye on VS Code!
I've heard lots of people say that Mongo doesn't scale very effectively, but fortunately the nature of how Complice works as an app is that it's usually tracking small lists of things (eg "what am I doing today?") not massive ones (eg "what are literally all of the tasks I've thought of doing in the last 5 years?") and there hasn't been that much of a need for normalization, so it's worked well for me.
To be honest, I didn't think about it that much when I got into it. I hadn't worked much with databases before building this app, so I didn't have a lot to compare it to. I liked the ODM that is Mongoose because it let me mostly ignore how the database actually stores things and just treat my documents like saveable objects.
All in all I'd recommend my stack to anyone whose main innovation is in the UI or other interfaces. If you want to do something that's very technically impressive or efficient, you might be better off with something else.
Our back-end is a pretty plain PHP setup: PHP7 + MySQL + NGINX hosted on Amazon AWS. As we grow, it becomes a bit more complex (sharded databases, etc.) but we started with the most basic thing possible and only change it when there's a real problem that needs to be solved.
The front-end is now in React, although we started with a pretty simple jQuery setup. I've heard React described as "10 times as much work for a 20% better user experience", and I think that's about right (maybe not 10x, but probably 2x). So in my opinion, something like React makes sense once the product is polished enough that small improvements matter, but I wouldn't want to hack together a prototype with it.
I'll admit that a part of me is jealous of companies that use managed services for their whole back-end (Firebase, etc.) because it would remove a significant amount of the devOps work we do, and that's one of my least favorite types of work. At the same time, being totally reliant on someone else's proprietary tech seems… risky. So for now I prefer to stick with commonly supported open source technologies, but I do sometimes think that the grass might be greener on the other side.
At the end of the day, our users don't care what tech we use, so I think it's a mistake to get too caught up in the holy war between different languages and frameworks. I already knew how to use PHP before starting Less Annoying CRM, so that was the right choice for us. But if I'd been a Rails, Node, or Python developer in my previous life, then it would have made more sense to use one of those technologies instead.
My platform is built on WordPress, both the front end and the back end. There is some custom development done to make different systems talk to each other and crons to clear out things daily, but mostly it is WordPress with Drip as my marketing automation and Mandrill for my transactional emails.
I've considered building a fully custom system, and some day that might be the right solution. But right now, with my back-end development skills lacking, it makes the most sense to keep it on a tech stack I know so that I can fix bugs myself without relying on an external developer.
WordPress plugins, all day long.
Many wantrepreneurs/micropreneurs/solopreneurs advocate starting with a WordPress product. They're right for many reasons. You don't need a lot of code or overhead. The product is distributed so you're not worrying about your server going down in the middle of the night. You can use WordPress's platform to sell your plugin. WordPress site owners are used to upsells.
But here's the secret sauce. WordPress site owners are constantly browsing the plugin directory and trying plugins because they're free and because it feels productive. They know they should be writing a blog post or managing their Google ads, but instead, they're clicking "install" on random things because the barrier to entry is so low. So as long as you can create a plugin that people might want to try, you've got traffic. Now all you've got to do is upsell them. :-)
Being an e-commerce business, our main priority is a reliable transaction, so we've built loads of custom functionality upon a highly customised Shopify storefront.
We use jQuery to handle customer data before a transaction, then use Zapier after a customer goes through Shopify and pays. We've found it pretty reliable and the trade-offs of speed over reliability were worthwhile, especially when we were coming off Kickstarter.
From there, the operational side of our business is complex, and people's pet photos are handed off to outsourced designers, emails, and eventually our factory. For this, we use a mix of custom MEAN stack and Zapier.
I'm an advocate of two things when bootstrapping: do it for free, and don't reinvent the wheel.
Now, that's not to say you shouldn't code things from scratch, or that 'free' means bad quality. Actually it's quite the opposite. There are plenty of amazing platforms out there that will give you a solid foundation at little-to-no cost while giving you the assurance that your product isn't going to go down when you need it to perform the most.
My product, Closet Assistant, is a front-end 'plugin' (like Intercom). It pops up on the retail website Poshmark and automates some processes for the users. It saves them time, and potentially makes them more money.
It runs on a serveless tech stack because it's mostly front-end code, with a sprinkle of back end for things like payments and task automation. Here's what I use:
- App/Website Hosting: Github Pages
- SSL: Cloudflare
- Back end: Webtask
- Authentication/Database: Firebase
- Payments: Stripe
- Analytics: Google Analytics
Every single one of these platforms costs me $0 to use.
Github Pages is super easy to use if you're a developer. Jekyll is a lovely static-site building engine. The reliability and flexibility is reassuring. Cloudflare is also incredible. It allows you to have secure pages and will protect you from DDoS/high traffic scenarios (Github Pages won't, necessarily).
Webtask is something I had never heard about until making this product, yet it's been the backbone of the project. For free, you can have a Node.js back end that allows you to receive GET/POST requests, and listen to webhooks. I use POST requests for creating new subscriptions, ending subscriptions, and updating credit card info. I use webhooks to disable accounts if the user hasn't paid, or to send out an email when someone converts their free trial. Oh, and it's already hosted and ready to go (with an easy npm integration). You just provide the code and they give you a URL. Pretty awesome.
Firebase is perfect for bootstrappers, because it allows you to quickly create new users, and the NoSQL database is incredibly easy to manipulate and use. I use the database to verify that users are paying, and keep track of settings/stats used in the app.
Stripe is a given. It's the most flexible and useful payments platform out there. Once you get your head wrapped around the API and their webhooks, it's very easy to build features that would be a massive headache on other platforms.
I use Google Analytics mostly because it's easy to integrate (and it's free). I have a separate tag for the website and for the product. It lets me track how and when my users are using the product.
It took me about a month to learn how to develop with these platforms and integrate them together. But, when in harmony, it's a killer tech stack that will allow you to scale at little-to-no cost.
Why this stack? Django has so much of the functionality built-in that it allows for quick and easy development and iteration of ideas. I would rather spend my time testing new ideas and marketing my product than re-inventing the wheel.
Docker/Docker Compose makes development and deployment simple. I can quickly and easily scale services when load begins to slow the system. I follow the YAGNI (You Ain't Gonna Need It) principle when it comes to most things, and right now I don't need auto-scaling infrastructure.
How does our tech stack relate to our business strategy? We want Manager's Phone to be the premier small-business texting solution in the United States (only the US, for now). We believe it can delight its customers by helping grow community in small business. I believe this strategy can be accomplished by quickly testing and learning from new ideas. Our tech stack enables this kind of agility.
Here's my advice for you: use what you know. I see so many entrepreneurs trying to use the latest and greatest tech to build new products. Don't get me wrong. I love new tech, and I love building new things. The thing is when trying to validate an idea, tech doesn't sell. Focus on tech you know and deliver value to your customers.