I agree - microservices are a technical solution to a people problem. Stevey's seminal "Platforms Rant" (https://gist.github.com/chitchcock/1281611) touches on this - the reason why Dread Pirate Bezos mandated services was not because Kubernetes was cool[1], but because their teams were too interconnected, moving too slowly, and Conway's law was getting in the way.
Splitting into services siloed each team and allowed them to move independently and by side effect, faster. Not due to inherent properties of (micro) services but because one goes faster by removing the things that slow you down.
As a startup, you do not have this problem. You likely will _never_ have this problem as your default future state is 'dead'.
Do the simplest thing that can possibly work - build a monolith using tools you know that give you the ability to predictably, rapidly iterate on the product.
After you hit some semblance of product/market fit and need to scale, you can do that. Scaling is a solved problem. Premature scaling is not.
[1. This is a joke. Kubernetes wasn't even a thought in Google's eye at this point in history]*
> the reason why Dread Pirate Bezos mandated services was not because Kubernetes was cool[1], but because their teams were too interconnected, moving too slowly, and Conway's law was getting in the way.
Not quite. Amazon's problem was that they were experiencing too much impedance between teams, and some teams were even siloing themselves to the extent they were creating problems for everyone around them. Bezos' diktat was intended to break through a bunch of petty office politics bullshit that was dragging down the company and preventing teams from delivering their work. The diktat boiled down to basically ordering everyone to grant access to the service they owned and provided to external teams that need it, no exception, and would be held liable if they failed to provide it, intentionally or not
Your three superpowers as a solo founder need to be:
1) Deep expertise and network with potential customers
2) Ability to empathize and connect with your customers and sell the thing
3) Ability to build some sort of MVP
The deep expertise and empathy will allow you to hone in on the problem you know your customers will face, and so you can narrow down the "paradox of choice" of different features/products you can build. It'll give you a much better starting point for experimentation and iteration. Start small. Talk to these folks. Get people to validate your idea. If you don't have an existing network where you can talk to 30-50 customers (100 is better!), this will be a problem.
The empathy and salespersonship will allow you to get folks to give you feedback and/or pre-sell the thing. Maybe do consulting for them to earn revenue and testimonials. If you can't sell this, you're going to have a hard time.
Finally, you need to be able to build something that delivers value to your customers. You don't have to be the world's greatest programmer (actually, if you were that might hurt you more than it helps!) but you do need some programming chops. Maybe it's automation around an existing process (a chatbot that does something small). Or even a spreadsheet. Maybe it's a full-blown MVP. Either way, you don't have the revenue to pay a developer, and sharing context with someone that you can afford is likely very very difficult.
If you don't have these things, this will be really, really tough. If you do, it will still be very tough, but you have a much better chance of being successful.
Find a network of solopreneurs - either something local to you (where you can meet up periodically) or an online group. This will be invaluable as you run into challenges they solved, and then you can pay it forward for the people that will walk your path later. And, having a place to vent with empathetic folk will help keep you sane.
If you need any help, I'm happy to share my experiences solo-bootstrapping my company to 20+ people. Just email me matt [dot] rogish [at] gmail
Always always always use a payroll provider. If possible (size permitting) use a PEO (JustWorks, TriNet, etc) to take care of payroll taxes and state/local unemployment registration/withholding etc. (especially if you are distributed and you have folks in many states). Getting this wrong can destroy your company, and PEOs are super cheap by comparison!
Absolutely agree with this. They have software that accurately takes care of so many fine details and at such a reasonable per-employee price point that you would have to be nuts not to use one as a small company. In fact it makes me believe Bannon just didn't give it much thought.
I agree. We moved from NYC to suburban Philadelphia (walk score of almost zero). We both work from home, which is great. But the house has been one project after another, and although there are ebbs and flows, there's likely always something going on. We're financially better off (our house is like 1/3 the price of our small 2 bdr rent in LIC) but the never-ending trickle of work is mentally taxing.
We needed to replace our washing machine when we bought the house, so I did the research and got the best front-loader we could afford. Turns out, due to $reasons, it vibrates throughout the whole house (it's on the second floor) and although it's working fine, every time we do the laundry we shudder at the annoyance. Now, we eventually will have to settle for a lower-performing top loader but I'm still not 100% certain that it won't cause the same problem, so we feel stuck. Keep the good, but frustrating, washer, or take a risk that another almost thousand dollar washer will have the same problem. Outsourcing these decisions and annoyances to a landlord is appealing.
Fighting entropy is a great way to put it - we had things come up that resulted in our inability to tend to the garden, and in a month, it's overwhelmed with weeds. That's my weekend project. Could we pay someone to clear it? Sorta. Service providers don't like (for obvious reasons) small projects, so nobody will return our calls when we say "It's like 2-3 hours of weeding". Could we find someone (say, a college student or something?) to do it? Probably, but it'd be almost more work to find and vet someone to do the work than it is to just do it ourselves. And, there goes a weekend. A weekend that, if we were still in the City, would be spent doing anything else.
I wouldn't trade it for almost anything, but it's not clearly the best solution for everyone. I would totally pay the equivalent of a "condo fee" for someone to manage all this nonsense.
Turns out, due to $reasons, it vibrates throughout the whole house (it's on the second floor) and although it's working fine, every time we do the laundry we shudder at the annoyance
This is why washing machines are usually on the ground floor in UK homes - usually in the kitchen, where they're close to the plumbing, despite there being very little overlap between food preparation and washing clothes.
For a B2B SaaS company, the easiest/most likely[1] algorithm to succeed[2]:
1) Be embedded in the industry for a while
2) Make lots of connections, build credibility
3) Build SaaS app to solve key pain point you experienced in #1
4) Sell to the folks you know from #2
5) For bonus points/de-risking: find 25 potential customers (from #2) and reach out to them and validate this idea (Jobs-to-be-Done). Get a handful of them to commit, even verbally, to buy this when you've got an MVP built.
[1] Clearly this is not the only way to be successful, but "I have a random idea lemme build it" is a great way to be not successful
[2] Succeed = your business that makes enough revenue to support you and a reasonable lifestyle, equating (and/or eventually surpassing) what you would typically make at a W2 gig, from a diversity of customers and not trading your personal time for money.
This is exactly the recipe I used and sold a company for $10m. Also, I am a absolutely terrible programmer and v1 of the product, with which this recipe was executed, was full of copy pasted code, unhashed passwords, all of the hallmarks of terrible programming. I got to $100,000 revenue before a friend of mine joined who actually knew how to program and rewrote the whole thing (literally zero lines of my original code were preserved).
I’m not the poster here but I’ve been involved with the sale of a few businesses like this and I consult for a VC. I’ll answer a few of these.
I’ve seen owners (either single or partners) who own between 5% and 100% of the business when they sell it. Unfortunately, most of them seem to own between 5 - 35%.
Most of the sales I’ve been involved with are the company trying to find a buyer. However, occasionally a VC will flat out ask if the company is for sale. Though it’s probably 10 to 1 in my experience.
There’s usually some level of negotiation. There is a “SAAS multiplier”. Right now the VC I consult for looked at about 3 - 5 times EBITDA. This gives you a healthy negotiation range.
People should absolutely consult an accountant and an attorney when figuring out what to do with the money they make. Often if you handle it right you can pay significantly fewer taxes. Taking stock or equity is a good way to handle reduction of those tax burdens.
I’ve seen people celebrate by buying multiple very expensive cars. A house on the beach in Hawaii. Huge trips. I’ve seen people blow huge amounts of money very quickly. The fastest was two guys who blew through $3,000,000 each in 6 months. It was stupid.
Most of the sales i have been involved in kept the former owners in a working capacity at the company.
I hope this helps a bit. Obviously it’s just my observations.
I made just over $1m because we raised a bunch of money for growth that didn’t pan out. Because LOL California the money went straight into a house. I still have a mortgage and a day job.
Bigger lesson is to buy a house as soon as you can. I’ve made more money on paper living in this house than building the company.
I kind of needed to raise the money. The wheels were falling off the bus because the software was so bad and it needed to be professionally written. I should have raised less and sold sooner though.
If you're at all interested in adding your story to this list or future lists, let me know! Sounds like something we could all learn from. I'm courtland@indiehackers.com
When I first saw indiehackers, I was in love with it. The execution was fantastic. You did a great job.
Then it got bought, and changed. Now it's forum-first, interviews second, and half of them are sort of locked.
Why do you now have to sign up for a forum to view the older product interviews? It's super annoying, so I just stopped reading. It also seems detrimental to the people who gave interviews early, they wanted press, rather than being hidden behind a sign up thing.
Is there any interest in reverting from this pinterest-style login-wall, or is that just too costly?
If this sounds blunt, it's only because I'm disappointed that a site a loved became less fun to use.
Walling off the content directories was an experiment to boost community membership signup, as community members are far more active than anonymous visitors. It's worked — people have joined the community at a much higher rate — but the downstream results haven't been significant enough for this to really be the backbone of our growth strategy. I will likely revert it soon in favor of other approaches, for example, creating search engine friendly evergreen content like this article.
Slightly off-topic, but what happened to indiehackers? I liked the page more before the redesign/stripe-takeover.
The page was more clearly arranged and you could browse it without being logged in or having an account. There is also this ridiculous "stripe-verified" badge for businesses doing business with Stripe now, which is not that interesting for indie hackers I guess.
It also seems the interviews are not that important anymore, but being some kind of community is - but I don't think that people want that, because we have that already here or at reddit - the nice thing were the interviews.
>> you could browse it without being logged in or having an account.
That's a fair point I hear quite a lot. Not sure what the reasoning is there (assuming it is the case).
>> It also seems the interviews are not that important anymore, but being some kind of community is - but I don't think that people want that, because we have that already here or at reddit - the nice thing were the interviews.
Have to really strongly disagree on this point... The IH community is - without a shred of doubt in my mind - the single most impactful thing Courtland has built at Indie Hackers. Happy to believe that you don't want that, but there are a lot of founders and lurkers on the IH forum who really do want it...
is closest to the old layout where each block linked to the founder interviews. I basically wrote the site off until today because it looked like the interviews had been walled off.
I read this story exactly the opposite: it doesn’t have to be perfect at the start. You just build something people want, and then hire a team to improve the back end (without destroying what people wanted it for in the first place).
Major companies have had security issues (such as Adobe) but that doesn’t make them a fraud.
FWIW, at that time Adobe was already properly handling the password - what leaked was an old backup. Where passwords were hashed, just not properly.
Adobe did mess up on that one - it's just not on the same level, not even close. The main thing that makes it worse was that Adobe has a lot of customer data (likely unlike this guy, who probably didn't have many customers)
I didn’t have any idea what I was doing. When my cofounder arrived and looked at the code base... he looked like he was going to puke. Took him less than 5 minutes to decide that there wasn’t even a line worth keeping.
Agreed, but there is a slight twist to that I have seen be even more effective.
1) Consult in the industry as a contract developer at X/hour rate.
2) When you find a problem that they're facing that you might be able to turn into a business, offer them 0.75X/hour while you work on it in exchange for the right to commercialize it.
Obviously this doesn't work for everything, but it's a non-obvious way to get paid while fixing a real problem and build a business.
2.b Be independent contractor. Carefully work on side-biz on your own time. Have good documentation and git-log in case someone at the client ends up caring when you worked on it (zero risk if it's not core biz for them and they aren't assholes). Don't tell anyone what you're working. Don't use proprietary data in your product. Profit
Again, every situation is different. But the benefit of bringing the client in is that they can act as your first reference client (the hardest to get), and that it's not job+sidebusiness, but a hybrid so your time is more efficiently spent.
1 through 3 is 100% correct in my experience. I left my job recently and after a short break I called 3 friends from the industry side and 3 friends from the customers-of-that-industry side and said "if I do this will you pay me?"
This has nothing to do with comming up with idea like the title suggests. And it's because having ideas is overated. You find good ideas everywhere, all the time. the execution matters the most, which is part of what you describe.
It's possible they disabled the localhost check at some point.
Edit: It does now, after Travis folk fixed it. :D
And, Rails (which I assume they're using) typically loads DB credentials from a `database.yml` file for a particular `RAILS_ENV` (local dev, local automated testing, prod). By setting the `DATABASE_URL` env var, they are overriding that (this is fine/expected behavior for app deployment as far as Rails is concerned; it's comparatively less common for localdev). So that bypassed the `RAILS_ENV=prod` check that might also have caught this (e.g. `RAILS_ENV` was undefined or `development`).
So I'd really have loved it if they dug into some of the UX factors to this issue:
* Why do they allow remote access to their production database? (Is it too hard to get a local database copy? "For debugging purposes"? Why was the eng in prod the day before? Was it unintentional? Should we revisit those assumptions? Should we resolve whatever issue that caused us to shortcut by allowing remote, direct prod db access?)
Why, for localdev, they override database.yml and use env vars (which I've found is more cumbersome to use and not as common). Yeah, in production you should use RAILS_ENV/DATABASE_URL/etc. - so are they attempting to have prod parity? Why or why not?
* Why are folks routinely logging in (for debugging purposes) with a DB user that is, effectively, root? I bet that user can `drop table` too. Should folks have a limited access account and then jump through a hoop or two for root?
It sounds like they want to "debug" prod by running some local rails tools (rails c?) with DATABASE_URL set to the prod db. Is that the "best" way to do it? heroku etc. actually open a rails console in the environment and not locally.
https://www.ReactiveOps.com | Sr Site Reliability Engineer (AWS/GKE Kubernetes) | Full-Time; 155-160k DoE; 0.01% equity | Remote, Right-to-work-in USA
ReactiveOps is a DevOps consulting and services company, focused on AWS/GKE. We setup, maintain, and operate Kubernetes clusters for our clients, setup CI/CD, migrate their apps into Kube, etc., in addition to day-to-day cloudOps works. We are in Slack with them and act like their "outsourced, in-house Ops team". Our goal is to exceed the capabilities and care of an in-house Ops organization.
We are a completely distributed team of 16 highly motivated folks, and are 100% bootstrapped and profitable.
I spoke to you at length and then your cofounder at length. Then it turns out that you don't actually have any immediate need to fill the role but you "might" have a need in the next 30 to 90 days. I pretty much gathered that you basically subcontract.
I'm sorry you felt your time was wasted; we do not aim to do that at any point in the process (it wastes our time, too! :D). We are a kubernetes consulting and DevOps-as-a-Service shop, and some amount of our demand's final materialization is unpredictable. We take pains to mention that in the beginning but, if we didn't, that's on us and I'll make sure we don't miss that again - thank you for bringing that to my attention.
I don't know your situation, but it's highly likely we had a significant influx of demand that suddenly softened, and we had to back-off on the hiring. Or, perhaps also likely, we hired someone that more closely matched the position and needed to pause the search (we have 3 people starting on Monday, Feb 5, for example; we've hit our quota of less experienced Kube experts and have re-focused on people with extensive cloud production kube experience).
As a profitable but bootstrapped firm that has (yet!) to lay off people due to underwork, we strongly bias against pre-emptive hiring.
I wish you the best of luck in your career, and if you are still looking, in your search.
>"I don't know your situation, but it's highly likely we had a significant influx of demand that suddenly softened, and we had to back-off on the hiring."
Except that I replied in response to a "who's hiring" thread and the interviews followed very close to my responding. So why would you even be posting that you are hiring if you had "demand that suddenly softened"?
I went through a very lengthy interview process with this company, and made it to the final stage. Had great conversations with everyone at every step and ultimately was turned away with no explanation whatsoever.
That being said, a lot of the folks I spoke with seemed pretty sharp. YMMV.
Although we strive to hire everyone who reaches the final stages (it's super time consuming for everyone, you and the team!), ultimately we have to turn away people who are awesome but aren't a perfect fit (at our teeny-tiny size back in [time redacted] when you interviewed, we were even pickier than we are now; I wouldn't read too much into our decision to not move forward).
We've made a lot of changes in our process since you spoke with us and I hope we're more communicative - to the best of our ability - in our process. I wish you the best of luck in your future endeavors!
I don't think it had anything to do with you. If you notice they always say they're "hiring" on these threads. However they don't necessarily have any new "client" to subcontract out to someone. They don't seem to have any problem wasting people's time though.
https://www.ReactiveOps.com | Jr-Mid-Sr Site Reliability Engineer (AWS/GKE Kubernetes) | Full-Time; $90-160k DoE; 0.01-0.1% equity | Remote, Right-to-work-in USA
ReactiveOps is a DevOps consulting and services company, focused on AWS/GKE. We setup, maintain, and operate Kubernetes clusters for our clients, setup CI/CD, migrate their apps into Kube, etc., in addition to day-to-day cloudOps works. We are in Slack with them and act like their "outsourced, in-house Ops team". Our goal is to exceed the capabilities and care of an in-house Ops organization.
We are a completely distributed team of 16 highly motivated folks, and are 100% bootstrapped and profitable.
EKS is likely to be in preview/beta for most if not all of next year. Even after it exits preview, you'd probably want someone else to kick the production tires. Given how Kube on EC2 is doable/manageable (that's what we do) I don't see a reason to stop. If Kube is the right choice for you now, it's the right choice on EC2, and once EKS becomes a thing you can migrate to, you can just do it.
Splitting into services siloed each team and allowed them to move independently and by side effect, faster. Not due to inherent properties of (micro) services but because one goes faster by removing the things that slow you down.
As a startup, you do not have this problem. You likely will _never_ have this problem as your default future state is 'dead'.
Do the simplest thing that can possibly work - build a monolith using tools you know that give you the ability to predictably, rapidly iterate on the product.
After you hit some semblance of product/market fit and need to scale, you can do that. Scaling is a solved problem. Premature scaling is not.
[1. This is a joke. Kubernetes wasn't even a thought in Google's eye at this point in history]*