Comment by quesera 11 hours ago
Ah, I do love the smell of fresh optimism in the morning!
I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions.
And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
I'm confused. Is Pinboard something that was built by this Maciej character? Acquired by him? What was the name of the product Yahoo bought and I assume shut down? FYI I don't see any mention of him here: https://www.pinboard.com/who-we-are
Your comment reads a lot like something you'd say during a chat with friends on a sofa in a café.
Not GP but a rewrite based on what I think they mean:
Maciej knew Delicious inside out, and he knew what Delicious being acquired by Yahoo meant. So he started building Pinboard (a Delicious alternative) in 2009, caught the various exodus waves from Delicious in the later years (esp. 2011) and ended up acquiring Delicious for $35k in 2017.
I think Maciej worked at Delicious, which then got acquired by Yahoo. He then created Pinboard as a Delicious competitor, while Yahoo ran Delicious into the ground (as he predicted). Then when Delicious users had flocked to Pinboard, he acquired Delicious from Yahoo.
> And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
Unless people somehow figure out a way of hosting stuff somewhere else than Amazon/$host_that_charges_per_mb_transit (Hint: they exist)
Considering it would have to be a lean operation (assuming bootstrapped), then figuring out basic stuff like "We don't want to pay per MB sent" should be a pretty high requirement.
Backup to Backblaze B2, or, depending on architecture, rely on their object storage for hot data (depending on data cache and tier requirements). They partner with Cloudflare for free egress (on the Backblaze side) of public content as well.
https://www.backblaze.com/cloud-storage/pricing
https://www.backblaze.com/blog/backblaze-and-cloudflare-part...
In Europe. Hosting for North American customers is a completely different story.
Dont OVH and Hetzner offer this? If you dont like bare metal perhaps run Coolify for your vercel like platform?
I don't think you'd have to consider migration all the data from Pivotal, but lets assume 10% just in case? Lets say that's 100TB in total (on disk), which you could host with 10x storage boxes from Hetzner, 24 EUR each per month, so 240 EUR in total, which includes 10 unmetered connections (1 per box).
> I don't think you'd have to consider migration all the data from Pivotal...
I do. You might not have demands to migrate all data from all of your potential customers, but far, far more people than you might expect treat their issue tracking system as a system of record and external memory for a HUGE assortment of things.
One hugely (and obviously) useful query chain that such a system answers is "Hey, this customer problem sounds familiar. Did we investigate it before? Did we solve it? If so, how? If not, why not?". For long-running projects, it is impossible to select the correct 10% of data to retain to also retain the ability to reliably -er- service those query chains.
The real reason this won’t work is that Pivotal obviously isn’t making good money if VMWare is cool with shutting it down.
If it was some kind of excellent business to be in it wouldn’t be shutting down.
An analogy would be to say that it would be a great business model to clone Redbox now that it’s gone. But it’s not because its competitors ate it alive.
Sure, there are a bunch of Redbox customers that liked the product, but that number was declining.
"Good money" to a company with $13B revenue a year is a lot different than "good money" to a solo developer. If you can pick up six figures a year in revenue and keep things small enough to run solo, it's a good business for you.
Why? Maybe the market just isn't there for that many work management systems. Or maybe it's not a fun and exciting product to create, so a solo developer isn't as likely to pick it up.
Remember we're not talking about the general case here. We're specifically talking about the feasibility of seeing a specific product being shut down, and then building a clone of it on a small resource budget in an attempt to snatch up their soon-to-be-former customers.
I’ve worked at a couple places that made the mistake of thinking they could charge a premium for artisanal hand crafted web pages. You get all the customers with deep seated control issues, willing to pay a premium to have everything exactly how they like it, and one by one sticker shock works as therapy and the price they will pay per artisanal, hand crafted webpage slowly declines until it costs you more to run the system than the customers will pay.
And in the most recent case of this I’m aware of, at least two different groups got to sell the company to new suckers before the bill came due.
Can you please elaborate more on this? Price they will pay for changes? Not getting it, is it that the target market is slow forcing owners to lower the price? Doesn’t explain “costs more to run” part.
To a first order approximation, Wikipedia serves everyone the same page. So the cost of pages in Wikipedia is proportional to the rate of edits, not the rate of page clicks and inbound links. Because once I hit Save, the page they display is pretty much the same one they'll show you when I send it to you to ask your opinion.
If I show each user of a website a highly customized, user- and workflow-specific page for the same url based on context and previous activity, then I have to generate it every time ("hand crafted, artisanal web pages") so the weight of the backend is now proportional to traffic.
Amazon.com tries to split the difference. You and I see the same bones of a page for an Apple Watch 10, but little bits load in and show you laundry detergent and me pickles. But Amazon makes more money every time I click on pickles and add to my cart, so there's an expectation that the fractional penny they pay to load the page fragment results in more sales. That doesn't work the same for SaaS applications, so you need to use even this trick sparingly, not build your whole product value statement around it.
For the control issues crack, the paying customer (not their users) is attracted by all the levers and dials, but cannot appreciate the cost using them exposes them to. The development cost can amortize over time, increasing your profit margins and letting you recoup the R&D costs, but the cost of keeping a cluster running cannot. And you've painted yourself into a requirements corner you can't get out of. Eventually their eye drifts to competitors with fewer high-cost, high-value features in favor of low-cost.
The best way to pull this off is to bet the tool will end up shutting down and build the replacement before it does. A good example of this is Pinboard: Maciej knew the product inside out, and he knew what being acquired by Yahoo meant. So he started building Pinboard in 2009, caught the various exodus waves from Delicious in the later years (esp. 2011) and ended up acquiring it for $35k in 2017.