How should a solo developer manage third-party services for unrelated clients?
Asked by
MellowPine47
I'm trying to understand the real-world setup for third-party services such as Resend when one developer builds backends for several completely unrelated businesses. For example, one client is a furniture store in New York, another is an electronics store in Texas, and a third is a nonprofit in California. They have different owners, domains, customers, and billing arrangements, but all need transactional email. Should each client have a separate service account, API key, repository, database, secrets, and infrastructure, or is it common for the developer to use one master account? Who creates and owns the service accounts, and how should access be handled? Also, are bounces, complaints, delivery failures, and usage limits checked manually, or are they monitored automatically? Finally, should the developer train each client to manage the email provider, or keep the provider account under the developer's control while offering a simpler dashboard inside the application? I understand the idea of one backend serving multiple frontends, but these are independent companies rather than different products from the same organization. How would you structure this so the clients remain isolated and can take over their projects later?
Answers
You generally should not inspect every dashboard manually each day. Configure webhooks for delivery events, bounces, complaints, and hard failures, store those events with a client identifier, and alert when rates or volumes cross sensible thresholds. You can still review reports periodically, but routine monitoring should be automated. If you temporarily hold the credentials yourself, keep one credential per client in a secure secret store and never mix them.
Reply to this answer
The key test is whether you could hand the entire project to the client tomorrow without relying on your personal account. If not, ownership is set up incorrectly. The client should control the provider account, verified sending domains, billing, and account recovery details. You can provide a short handover guide or training session, while the application can expose common email settings and delivery status in a simpler dashboard if that is useful.
Reply to this answer
Use a separate account and API credential for every client. Their sending domains, email reputation, usage limits, invoices, and data should stay isolated. If one client has a bad mailing list or gets compromised, it should not affect the other businesses. Never put multiple clients behind one shared credential, and make sure the system cannot accidentally send one client’s messages through another client’s account.
Reply to this answer
Treat the clients as completely separate organizations. Each should own its own service accounts, billing, repositories, databases, secrets, backups, and production resources. The developer can set everything up and administer it, but the accounts should be created in the client’s name and ideally paid for with the client’s billing details. Grant the developer only the permissions needed for development and operations, while keeping billing and ownership with the client. Reuse code, deployment templates, and infrastructure patterns—not production accounts or shared resources.
Reply to this answer
Add your answer
Answers are reviewed before publication.
QuietMango81: So the client would normally create the provider account using a company email, and then give the developer the appropriate access or invite them as a team member?