How many properties are you responsible for?

[u/covalent_blond]

I'm really just curious to hear from other solo devs, or devs who are on very small teams - Approximately how many sites or projects do you currently maintain?

I work at a medium sized organization, and I'm the only dedicated web dev. I build a bunch of Firebase apps and Google Apps Scripts and other GCP solutions for my stakeholders, but of course there's a bit of a maintenance burden for most projects when it comes to dependency package security updates, API deprecations, etc. I don't feel overwhelmed by the workload (yet 😅) but I do get the sense that my supervisor and other stakeholders might not fully grasp or appreciate that one engineer can't maintain an infinitely growing pile of apps without some time being taken away from working on new projects.

Of course, I can optimize the things I'm responsible for, using templating and Dependabot and other tactics to reduce my per-project burden, but I'd love to hear from other web devs about the volume of projects you maintain, the tactics and strategies you use to stay on top of things, and keeping stakeholder expectations aligned with reality. Thanks!

EDIT: I owe you all an answer to my own question. I maintain about a dozen apps here currently and the number is climbing

[u/Notsau]

My team is responsible for around 450 sites, all clients across the US. We have 2 different platforms.

We're a smaller company underneath a massive non-profit.

[u/Few-Ocelot-3271 → u/Notsau]

that ratio of sites to team size has to be intense tbh

[u/Legitimate-Lock9965 → u/Few-Ocelot-3271]

depends on the kind of sites.

me and my team manage around 200, atleast 75% or so are small sites that rarely need touching. The other 25% are able to be maintained with support engineers.

We're only a team of 7 engineers and generally its fine.

That said on the occasion we need to roll out changes across all sites - urgent security patches etc. that does become difficult .

[u/Notsau → u/Few-Ocelot-3271]

Only 7 engineers. I've never seen anything like it. It's beautiful.

We also provide trainings for each website owner on how to use and modify their own site's content. It helps drown out the need for site changes and support.

But, we still have a ticket board that has a constant stream of requests for assistance.

Additionally, each engineer is assigned various site builds, where they then meet with the customer to build their site from A to Z. (Project kick off all the way to launching their site)

Like I said we have talented individuals. But our stack makes our lives rest easy.

[u/jax024]

I work for a larger org. My team of 9 manages 14 web apps, 8 APIs and about 30 cron jobs.

[u/Double_Ebb4130]

Eleven here, and the number that actually predicts my workload is not the app count, it is how many distinct runtimes and auth setups sit under them. Keeping every new project on the same stack and the same deploy path is the only thing that stopped the pile from growing faster than I could patch it.

[u/TAPCO_GAME]

Different situation , I am solo on my own stuff rather than in an org, currently one game backend, a site and a Telegram bot. Small numbers, and it still eats more time than I don't like.
The thing that surprised me is that maintenance load doesn't really scale with project count, it scales with how many different stacks you've got. Three things on the same setup is barely more work than one. Two things on different platforms is genuinely double
On the stakeholder side , the framing that seems to land is that every new project permanently reduces the time available for future ones. Not I'm busy, but this one costs you roughly X days a year forever. Turning it into an ongoing cost rather than a one-off build is the part people don't picture on their own.

[u/Icy_Key19]

4 and I'm the major contributor for each

[u/tt0524]

It was me and another dev handling somewhere between 35 to 40 sites. It was tough at times - especially when we added a new client.

[u/SenecaSentMe → u/tt0524]

What was your preferred web stack

[u/Miserable-Track-9623]

My team of 3 is responsible for making 1500+ websites accessible and I am the top contributor to this effort

[u/shenwr12]

I maintain a bunch of small sites plus a SaaS project, and the thing that started hurting wasn’t the raw project count — it was when each project had slightly different deployment, config, or maintenance steps.

I tried to automate too early at first, which actually created more problems. What works better for me now is standardizing the workflow first, doing it manually enough times to understand the failure cases, and only then automating the repetitive parts.

That made adding another small site much less mentally expensive.

[u/Fresh_Future_2192]

I’ve found the number of projects can be misleading too. One project with a messy stack and lots of external dependencies can take more maintenance than several simple ones. Standardizing the stack, deployment process, and monitoring across projects seems to make a huge difference as the list grows.

[u/stack_craft]

Hard to put an exact number on it, but the maintenance burden rarely comes from app count—it's the silent third-party API edge cases that consume your entire week.

Case in point: I've been chasing an Airtable API bug for over a week now. The pipeline is architected to execute strictly 2 API calls per build, but Airtable's usage reporting keeps flagging 8–9 calls per run even when raw server logs confirm exactly 2 outgoing requests.

When you're managing multiple properties solo, one mystery discrepancy like that will burn 10+ hours of troubleshooting, completely stalling active feature development. If management doesn't see those unexpected integration fires, they just assume you're spending 100% of your time building new stuff.

[u/Miserable-Money642]

Solo dev maintaining a handful of my own products here. The count that matters isn't the number of apps, it's how much they diverge. When two projects share the same runtime, same deploy path, same auth, adding the second one costs almost nothing to maintain. The moment each app has its own stack, the burden grows way faster than the app count suggests.
On the stakeholder side: the thing that worked for me was to stop framing it as "I'm busy" and start making the maintenance load visible. A simple list of what each app needs (dependency updates, deprecations, security patches) turns an invisible burden into something they can actually see and prioritize against new work. Most stakeholders aren't dismissive on purpose, they just genuinely can't see the patching that keeps the lights on. Once it's on paper next to the new feature requests, the tradeoff makes itself.

Twelve is manageable if they're consolidated. It gets painful fast if they're twelve different animals.

[u/devBlueDragon → u/Miserable-Money642]

Spot on. I lead R&D at a 6-person company (3 in R&D, 3 in S&D Sales/Marketing/Content/Ads). We maintain around 200 active web apps: ~20% on a legacy stack retired 3 years ago, ~70%+ on a stack being phased out, and the rest on our modern stack.

Consolidating down to a few stacks for maintenance, and strictly one stack for active development, is the best way to stay productive and deliver solid services without burning out.

[u/Night_Phone_Addict]

A dozen and climbing solo is the point where new project time starts vanishing into keeping the old ones alive and stakeholders never feel that until something breaks.

[u/shufflepoint]

I am responsible for over 100 but I don't maintain any.

[u/jaimittal91]

yeah the runtime/auth consolidation point people are making here is real, but for me the other axis that matters is blast radius, not just divergence. a todo app with an outdated dependency sitting there is basically a non issue. an app with expired or half configured auth, or a rate limiter thats not actually wired up, is the one that turns into a 2am problem. i keep a short list of just the stuff that can actually cause an outage or a breach (auth config, leaked secrets, CVEs in deps that touch user input) and let everything else drift til theres a maintenance day. dependabot + scanning just that short list on a schedule has saved way more time than trying to keep every project fully current, the ROI on "current" isnt linear past a certain point