AWS or Google Cloud When You Build Software for Other Companies

AWS Organizations and Google Cloud's resource hierarchy of organizations, folders and projects both let you keep client environments separate with their own billing and access boundaries. AWS's model is more granular out of the box, which helps when a client wants detailed IAM controls; Google Cloud's folder structure is simpler to reason about when most of your clients just need a clean, isolated project. If you're running ten or more client environments at once, spend time getting this structure right before you onboard your first client, because retrofitting account boundaries onto a live client's environment is painful for everyone involved.

Unlike a SaaS company that owns its infrastructure forever, a dev shop often builds something a client will eventually run themselves or move to their own preferred vendor. Favor patterns that transfer cleanly: infrastructure as code the client's own engineers can read, managed services with clear equivalents on the other cloud, and documentation that assumes the next person reading it wasn't in the room when you built it. A project built entirely around one vendor's most proprietary services is a harder handoff regardless of which vendor it is.

Favor these patterns so a project transfers cleanly:

• Write infrastructure as code that the client's own engineers can read and run without your team in the room.
• Choose managed services that have clear equivalents on the other cloud, so a later move stays realistic.
• Write documentation that assumes the next person has never seen the project before.
• Hand over account ownership at the end of the engagement rather than leaving your own credentials active.

Different clients bring different constraints: one already has an AWS enterprise agreement, another's CTO has a strong Google Cloud preference from a prior job, a third has no opinion at all. Rather than forcing every engagement onto a single house platform, keep working competence on both AWS and Google Cloud across your team, and let the client's existing footprint or stated preference decide by default. Reserve your strongest internal opinion for the projects where the client genuinely has no preference.

In client work, a bad deploy doesn't just cost you an incident, it costs you the next contract renewal. Shops that treat deployment pipelines as a core deliverable, with automated rollback and clear recovery procedures, keep their failed deployment recovery time short regardless of which cloud they're on; shops that treat CI/CD as an afterthought see recovery stretch out no matter the vendor¹. Build the pipeline discipline once, as a shop-wide standard, and apply it to every client engagement rather than reinventing it project by project.

It's easy for a dev shop to lose track of what a dozen small client environments actually cost to run once free-tier credits expire. Set a recurring monthly review where you check every active client account against its budget, not just the big ones. Both AWS and Google Cloud offer partner and startup credit programs worth applying for, since they reduce your own carrying cost on projects between milestone payments. Treat those credits as a cushion, not a permanent subsidy you plan around.

A client who wants a full infrastructure buildout on a platform your team knows less well should see that reflected honestly in the estimate, not absorbed silently into your margin. Scope a ramp-up period explicitly when a project calls for the less familiar of the two clouds, and say so to the client rather than padding hours without explanation. Clients generally respect a shop that's upfront about where its strengths lie over one that pretends equal fluency across every platform. This also protects you from underbidding a project because you assumed a familiar architecture would carry over when it didn't.

It also shapes how you staff the engagement. Pair a senior engineer who's fluent in the client's chosen platform with a more junior one who wants the exposure, rather than sending your least experienced person in alone because the senior team is busy on familiar work. The client gets a competent delivery, and your bench of platform coverage grows a little wider with every unfamiliar project you take on deliberately instead of avoiding.

Write this staffing logic into your internal project template rather than deciding it fresh on every proposal. A shop that has already answered how it handles an unfamiliar-platform project moves faster at the proposal stage and looks more credible to the client asking who exactly will be doing the work.