I hired a broker. Paid them no upfront fee, just a % of the sale. Maybe it was around 5%?
I had meetings with potential buyers and received a LOI (letter of intent) at a price I was comfortable with.
After that came 6 or 7 months of due diligence! I wasn’t expecting the process to last that long, but the buyer took time to interview my employees and secure a loan. At the end of each month I’d have to update my complete financial statements and the buyer would have to review them and they’d get submitted to the loan application.
Finally, the sale closed and I received a wire transfer.
I stayed on working for free (or maybe minimum wage?) FT for about a month, then part time for another month or two, and then finally on call for 1hr/week but no official office hours for another few months, just to make sure all the operations and handoff went smoothly. 6mo after the close I was officially done.
John Warrillow’s book Built to Sell has some good advise.
My main takeaway: first ensure the company is optimised for sellability.
And your question is answered too: agents. There are people and companies specialized in selling companies. Just like there are people specialized in buying companies.
> first ensure the company is optimised for sellability
there are a lot of things you can do easily early on but become very hard later:
- ensure the culture of the company doesn't require you to be there for it to function
- make sure your incorporation structure is amenable to selling easily
- separate out the accounts (both bank account and SaaS/PaaS/Iaas accounts) from day one, separate from any of your other projects
the Warrillow book goes into far more breadth and depth than this comment, but I just wanted to highlight that there are strong reasons to act now to shape things in a way that make it easy to sell, even if you don't currently intend to sell. being prepared to sell at any given time increases optionality / makes it so that in case you suddenly _need_ to sell, you don't have to put in 6 months of work before you can even put the thing up for sale.
It sounds planned in hindsight but it was pure luck. None of us had any idea how to do it. The reason luck was in our favor was because it wasn't a 1-man show, our location, aiming our communications not just at customers but always keep in mind our competitors and potential investors will (and should) hear us too.
We started eating our competitors lunch so they did have no choice but to take an interest. First we were an annoyance a few years later we had offers to discuss, then it became once or twice a year. We took every opportunity to engage but only for getting to know them but didn't take it further.
We were very visible because there were 3 of us in 3 different countries "making lot of noise" about our product.
Also timing wasn't good yet (why sell today when you know you'll be worth 5x in 2 years).
We went for ~5 years without considering selling and always positioned ourselves to eventually sell from the day we founded the business. If you think about selling when you're just starting, you end up constantly thinking if the company can be easily understood by an auditor and explained to an interested party.
We (3 partners) were already present in 3 countries/sites from the beginning so there was potential of messy "organic growth". And the only way to fix this do this was with a holding company.
- holding company to keep things simple and easy to explain and audit, e.g.:
- No difference in the contracts with our individual CEO's / sites that have to be negotiated individually when the company is acquired/sold
- an investor that takes over the holding has the keys to the kingdom
- all important negotiations done in the holding
The holding also made sense because it allowed us a presence in a 4th jurisdiction that is known to have a high density of investors and none of us would feel the main site is in one of the 3 jurisdictions that the partners were. So it kept things neutral.
Another thing we did right was never touch things we weren't experts in at least not until we had the first hire to move this forward internally, so we hired one of the big 4 to help with controlling & finance.
We had lots of internal bickering, I hated the idea of all this complexity with the holding, and the whole thing almost went tits-up before we even started. But implementing a holding within the first few months was the single most important decision for us. We might have gotten lucky without but not for the same returns.
Also sold a business of similar size to the parent. Basically if you're sub $1M revenue and not growing massively, then the broker websites are good solutions. Anything else, most businesses will be sold via investment bankers, an acquirer will come out an seek you, or you reach directly out to a potential acquirer.
One approach is to find someone (or a few people) who are well connected in the space you're in and offer them a percentage of the sale if you close a deal with a buyer they've introduced you to. AIUI, 5-10% seems fairly typical, at least for a smaller company. Obviously you'd want to have a signed, written agreement in place with any such intermediaries.
I have thought about the same, but over time I've started telling myself that these people (the sellers) just want an exit (e.g. because the market is falling apart), regardless of what reason they give.
I have only looked around in guest mode/logged out and haven't paid or anything to actually speak to the seller and get a fuller picture.
Are you happy with your purchases so far? What advice can you give me as a person that has a similar plan?
There are lots of reasons to exit and yeah you can't fully trust the seller when it comes to that.
Lots of people simply like to jump from project to project so being able to exit a business is great for them. Other people are retiring or get sick. Sometimes the business plateaus and they have owned it for several years and are tired of planning more articles for that niche. Some built it recently for the purpose of selling and it has terribly quality content and will likely tank in traffic in the next 12 months.
You also can't trust the seller when they say how many hours they work or believe they account for all their expenses (which is sort of a joke for content businesses anyways because almost all the expenses are added back in when accounting for the sale price anyways).
But for the type of businesses on there it doesn't really matter what the seller says, most of it is noise.
You can get all the insight you need into a content business using Google Search Console, Google Analytics, Ahrefs, and manually looking at it.
I built a content site from scratch for ~1 year before buying any and was looking at ones for sale during that time so by the time I went to pull the trigger I was "relatively sophisticated". Actually I only bought them in the last few months but so far so good, everything has been as expected. I'm strategically merging them into a single larger site and that is going well (one already successfully merged but waiting for ad network approval for the second)
These days the secret is you have to hire the good South Americans.
Exploit the fact corporate America hasn't caught on to routing contracts through Upwork et al. Then don't get greedy, keep the TCE delta below 20%, so they stay more than 9 months.
You can take your pick of the finest FOSS contributors Guinea and Paraguay have to offer.
Your secret path to success with international hiring is to avoid any country you know the name of.
Don't think you're thinking out of the box hiring from Brazil/Israel. Hunt down a decent dev from Ghana or Georgia.
If my Slack/Discord buddies are anything to go by, there's an extraordinary amount of gems out there who've made the choice to raise their kids in their home countries.
There's good talent in Thailand as well. RIP my friend the Thai data/cloud principal eng banking 14k USD.
When you read the book, ole Fred is not a fan of large engineering units. Forget two pizzas (Bezos is from New York, two pizzas for him is ~10 people).
Fred's view is actually:
1x captain/tech lead,
1x co-pilot,
1x ops guy equivalent,
1x business analyst equivalent who can be sent to meetings (he worked for IBM).
(And then two secretaries. And an copy editor for the documentation, because no internet.
No internet! The documentation must be written!
The lead developer needs to follow my favorite advice of all time:
Can't write? Imitate Hemingway.
And a full-time librarian for the punch cards. And a full-time employee just to maintain the minicomputer that was your debugger.
Because hey, the book was written in 1975.
The internet doesn't exist, email doesn't exist, the engineers almost certainly can't touch type. And anyone without an attractive female secretary was nobody.
The pimply faced youth's job as config wunderkid and unofficial court jester fills most of those roles these days)
Your comments are difficult for me to understand, although you do have a fun and whimsical style!
I wasn't taking it as gospel and I agree some engineering outfits are (or at least appear to be) overstaffed or inefficient, and a small number of very driven and talented people can produce some incredible things. But when it comes to making a product it can take a radically larger amount of engineering effort than it would appear.
PS Semi is an example of an ARM-beating company which was founded by a visionary engineer who almost certainly had the big ideas himself or within a small group of technical leadership. It still took a hundred engineers 4 years to bring out their first product.
To be fair with the book, that's what he describes as what he thinks a team should be. Not only there is margin for having more than one team, but the rest of the book completely ignores it and is about real people on real teams.
It was a fabless company so you basically write code and send it off to get built.
There's more details to it, but a single person could write a very small CPU and put it on an FPGA (or ASIC if they have the tools) in a few months.
That's just one example though. There's lots of software examples. Compilers, browsers, OS kernels, database servers, hypervisors. A single person can write any of those, but to make a competitive product it's often a very different story.
One of the most interesting things about hardware vs software is the barrier to entry.
Hardware intellectual property has an insane number of working parts and "factors" (electrical resistance, photo-lithography, metal layers, silicon is amazing) all have to be solved.
Software by contrast, follows the open source model. All those things you mentioned, are being done by people and academics in their space time on the internet. You're essentially assembling pre-configured tools
Hardware is more difficult, because the laws of physics are FAR harder to account for, than tying together APIs. Because APIs are after all, designed for humans to be able to understand and configure.
Software is also complex, but the good people in FOSS have already assembled their shit for free and are giving it to you.
Additionally, basically no hardware IP and blueprints are open sourced. Because of the free flow of goods (and not services), someone in an IP disrespectful country will clone you and sell your goods internationally. You have basically no resource to pursue that individual.
Launching an IP disrespecting internet business at scale however? That is almost impossible. As soon as your IP disrespecting competitor gets going, you can hamstring them.
Hence for hardware, create a develop, release, iterate cycle, and keeping the money flowing, you essentially need to employ a LOT of people to get your startup going.
Hence VS fund about 10 SaaS startups per hardware one.
Mostly I was talking about SaaS with the "make your first two engineering hires like this" guide. Clearly for photo-lithography with silicon on leading edge nodes, you just cannot do that.
> Hardware intellectual property has an insane number of working parts and "factors" (electrical resistance, photo-lithography, metal layers, silicon is amazing) all have to be solved.
Again, fabless companies don't have to do any of this. You get a PDK from the factory which provides all these parameters and even standard cell libraries so you don't even have to do circuit design. You just feed your logic into "compilers". You need "physical" designers to optimize the output of those stages, but these are not people looking at the physics, they just optimize P&R and floor plan according to the PDK specs and tool output basically to close simulated timing.
In practice once you get to a large enough and high performance product, you would need custom circuit designers. And step up even larger again and you'll likely be working directly with the manufacturer on defining and tweaking the process. At Apple scale, you probably even define your own custom process node. Once you get to this scale though it's pretty much like big software houses writing their own libraries or OSes or compilers or asm code because the standard available stuff is not quite enough. That all takes a lot of engineers too.
But that's not _required_ and almost certainly PA Semi would not have had a whole lot of engineers on that work, it would have been logic, analog, PD, V&V, power, primarily. And almost all would just work on the standard package they get from their fab. So mostly writing "software". And you don't need any money for a develop,release,iterate cycle on most of the hardware stack because it can be and is simulated.
That's exactly what happened with Twitter. It was at a company named Odeo.
But yes, I think you can have two high quality employees make good software? I mean they're employees, you're going to give them marching orders to do something presumably.
This is hard to achieve because generally good engineers are either working high pay tech jobs OR they work in a startup as founders / early employees with make-me-rich shares.
Sure, there are exceptions who don't know their worth. In general it's hard to find mediocre technical cofounders and very very hard to find good technical cofounders.
I think the assumption here is that this is a Hackernews thread about someone asking how to make their startup succeed.
Therefore, I wrote the post with some sort of assumption that OP is the technical founder. Hence OP is supplying the stuff like the vision, the outline of the tech stack, OP probably made a lot of stuff themselves.
Hence, it was more a guide on how to find extremely dedicated and good engineers to work for you, the founder. And how to deploy them to take load off you as the technical founder.
As a technical founder you rapidly become far more important as a store of technical knowledge. You're off to customers doing technical sales, networking with people you know for hints at how to solve your technical problems, etc etc.
Hence,what OP needs is top quality execution while they go off and do all that stuff. And ye ole Ghanian FOSS committer is the tree I'd shake.
Depends on the product what you actually need, but I've personally watched more than one successfull software product launched with a more or less this resourcing. Not exactly this recipe but very much in the ballpark.
The assistants aren't assistants - you hire them with minimum pressure, but try still to find the most talented junior you can find.
I'm sure you can be elastic with the mids depending on how much AWS there is to configure or some-such.
2 juniors in a startup is a bit, probably not the right thing. You'll run out of junior work surely?
The "two good ones plus exactly one junior to make them feel important, and to keep the show on the road for 2 weeks in case they both quit simultaneously" formula is pretty solid.
To be specific, my experience was from non-web software.
I would consider "junior" here not as a person in non-critical role who cannot function as an individual contributor, but as a solid candidate that lacks industry experience but can be at the moment hiring be expected to quite fast grow into the role of a solid IC. I.e to use a bit too stereotypical characterization
- not a "stablehand" but a "journeyman apprentice".
At the moment of hiring you don't count on it that they can deliver (but guess and hope), whereas the seniors will have shipped products under their belt.
Mid = journeyman, "worked another job before". Independent, trusted to be delegated to for specific things, but doesn't quite have a personal brand.
Senior = Master. Proven track record, proven reputation of delivering, capable of leadership inside a technical project. Has and maintains a reputation as someone you can trust.
Principal = Mentor to seniors.
Ofc there are shades of grey between junior and mid, because junior-ship takes like 2-3 years to grow out of.
The list of work able to be delegated to someone at the start is not all that large in many cases.
You won't need more than 2 engineers at the beginning for 99% of the startups.
Almost nobody is making anything technologically significant - and if they do they raise millions and act like a disorganised mid company.
In order to do your typical backend + frontend work you won't need much more, unless your developers can't code.
What are you talking about. IBM and other corporates defined the word outsourcing in the late 90s. I remember managing folks with 2 phds that were 1/2 if not less of my salary and I was fresh out of college. I watched as quality of folks went south over time as pay increased for them. My biggest frustration in the end was trying to train new person every 6 months because corporate wanted the same budget. They literally went from a 2 phd guy to barely out of coding shill within 2 year period. Market economies will sort this out.
That perspective makes it seem like US workers are paid too highly, which I do agree with. But the parent comments I'm replying to are speaking from a leadership perspective and seem just overjoyed to be exploiting workers for nearly nothing.
Edit: I reread my comment and I can see how I wasn't clear. I was actually replying to the parent of the comment I actually replied to, my mistake. I am glad the Thai wages increased, but GP was straight up flexing about paying people nearly nothing because they came from a poor country.
Plays some kind of role for sure but there are barely any local developer who work for a company abroad like it's common in Eastern Europe or other places (not counting foreign remote workers).
Oh, I could be wrong on the number. It's extremely low though, certainly in the teens.
As a person they're very opinionated about not working for a "product company." And have worked at the same company their entire tech career after bailing out of some traditional engineering discipline (I think 6 yoe?).
Sweetest person ever. Never really followed up that conversation when I asked them if they were considering remote.
Brazil is the beachhead in many ways. Huge market, easier to sort out all the employment stuff because it's a path that's much more well trodden.
If you still want to get an edge these days, you have to be prepared to go to the global platforms that give you access to devs in the really obscure places.
Nobody is hiring from Trinidad and Tobago because of the legal barrier to entry. But you can if you are clever with Upwork and similar.
If the code of the app is made by remote people in remote countries, how do you sell software to the US government? What do you answer to “What is the nationality of your developers?”?
A few accelerants:
1) Hired talented engineers in low cost of living areas in the US.
2) Started replacing myself by hiring multiple managers, which helped when I sold the business as it was no longer just about me.
3) Converted long-term clients to pre-paid retainer billing with helped create predictable workloads and revenue streams.