The scenarios I have taken extended downtime for. When an OLTP's DB needed a serious overhaul for some reason and it was cheaper for rollout to plan operational downtime than risk loosing data or inconsistent transactions. Generational platform migration to complete system rewrites (something I am generally against, but that is its own soapbox). Migrating from on-prem to cloud infra, which required design changes. In all cases data integrity/consistency is the critical aspect. Migrating from one db technology to another (MySQL -> PostgreSQL).

In all those cases there is serious planning done before the migration, checklists, trial runs/validations, and validation procedures day off. If something isn't working, the leadership group evaluates the the issue and determines rollback vs go forward. Rollback needs to also be planned for, and your planned downtime window should be considered.

I agree with you, this wording implies they are making changes after this change. This could've been bad planning, a bad call day off, etc.

In one scenario, we _had_ to go forward while resolving several blockers on the fly. We had planned ahead of time developer rotation shifts. Pulling people off the line after 8-12hrs. At some point, you aren't thinking clearly understress. Don't know how big the team is over there is, but I hope they are pacing themselves, during what I am sure is a horrible moment of crisis to them.

My advice to them is, consider a roll back if needed/possible. Split responsibility between who is managing the process and dealing with specific problems. Focus on MVP. Don't try to _fix_ and replace at the same time, if something was broken before business wise, log it in your bug tracker and deal with it later. Pull people away if needed to get rest. Get upper management away from people doing the work, have them only talking to the group handling the process management.

Edit: I am also making a good faith assumption that this is planned and not an emergency response, either way, it doesn't change my general advice.

The maker people I know have been migrating away from Tindie because it has felt like a sinking ship for a long time.

I really like the idea of Tindie so I hope they can succeed. I don’t understand what sequence of events led to this being such a large problem that they can’t even keep their site online. The post says something vague about the engineering team is hoping the migration work is close to finished, but it’s been years since I remember any engineering team knocking out the entire site for days without being able to restore it during a failed migration. Are they outsourcing dev work to the type of agency that bills by the hour and perpetually churns low hourly cost work to make their money in volume fixing their own code?

You have to wonder why it's so hard to put that on their 503 error page. I suspect something's much more broken than they're letting on.

They are putting out a lot of stuff that to me is very obvious to read between the lines what led to this because I've been brought in to clean messes like this before:

>The goal of the current maintenance is to fix a lot of long-standing issues with the site. The underlying infrastructure was getting very fragile as technical debt accumulated over time. A team is working very hard right now to make sure that once the site is back up, it's on much better footing and will be solid and reliable for the long term. Despite the unfortunate amount of time this is taking, it will be a major benefit to the site in the long run.

They are saying it was "spring cleaning" or a migration that took out the site for days. "infrastructure getting very fragile" reeks of bad or nonexistent ops practices, probably very little or unreliable IAC (if any, I've seen shops get by for 10+ years by just clicking things in console, til unfortunately it gets to this point).

This though, rubs me the wrong way:

> We want to offer a much better quality of service going foward. We understand that the lack of communication has been frustrating, and I have been closely watching social media and reporting the community's feelings up the chain, so your voices are being heard. The plan was not to have a long outage like this, but due to factors beyond the dev team's control, things have taken much longer than anticipated. Please be patient with us - I will keep updating here and on our other social media.

"Factors beyond the dev teams control." Sorry, no. If you have an ops team, you don't get to toss blame over the wall like that, and if you don't, you have no one to blame but yourselves. I feel bad for whoever the unofficial official ops dude is right now. These kind of infrastructure "tech debt" woopsies come from years of people just not giving a crap to doing things properly, it's never seen as important until it suddenly is. Hope they learn a lesson and hire an infrastructure guy properly. There's long been a persistent delusion in the pure dev world that they should be able to be completely agnostic to the hardware lying underneath their beautiful code - ideally yes, in practice almost never, unless you come from a place that has the significant resources to make something nice like that, or are willing to pay out the azz for managed cloud services or licenses.

Can you share more information about the undercutting? I've heard of places like Elecrow trying to incentivize people to sell via their platform/OEM service but it sounds like you've had people asking you to license your designs?

Free market is a good thing.

I see this a lot with small independent sites with big userbases. Instead of being honest, they hide mistakes behind maintenance or blame it on hackers.

Scheduledn't maintenance.

This really tickled me, I wasn't expecting them to just be a pair of esp32 dev boards you attach to your ears

Not everyone has seamless blue/green deployment.

However, any downtime over an hour or two screams "migration gone wrong" to me.

Otherwise wouldn't you just roll back to get the site up to come back at it and try again later?

So many fairly popular apps, SaaS, etc are on skeleton crew staffing-levels. It'll probably get worse with vibe coding. Though then they'll probably launch Claude Ops, etc now that I think about it.

It's like Etsy for small-scale electronics - if you build a cool, niche electronic device as an individual, Tindie is a marketplace to sell in low volume (possibly as a kit).

Tinder for indie (hardware) devs and their customers. I.e. a webshop for indie devs who sell small series of niche hardware.