Do you have partner tiers or certification?

Not today. A useful first collaboration matters more than badges, tiers, or volume commitments. Any future program will be based on demonstrated customer outcomes and clear operating standards.

Do you pay referral fees?

There is no standing referral scheme. Commercial terms, if relevant, must be agreed in writing before an introduction and disclosed where required.

How is customer AWS access handled?

The customer approves each access path. Read and write remain separate, roles are scoped to the job, and one partner never receives access merely because another partner has it.

What should an initial note include?

Name the customer job or integration, who owns the relationship, the expected outcome, relevant AWS context, and what you want Zerverless to contribute.

Bring clearer serverless decisions to a shared customer.

Zerverless works with AWS specialists, software teams, consultancies, and technology companies when responsibilities, access, and customer outcomes are explicit.

There is no open referral or reseller program today. Partnerships are scoped individually.

Start with a concrete customer job.

A partnership is useful when two distinct capabilities make the outcome better without making ownership harder to understand.

Delivery partners

Use Zerverless products, templates, or focused architecture support alongside implementation work your team owns.

Technology partners

Define a practical integration for shared customers working across data, deployment, observability, security, or GenAI on AWS.

Design partners

Bring a recurring serverless problem and help shape a product workflow through real constraints, review, and structured feedback.

Know when a partnership is worth pursuing.

A good starting point

A named customer problem, workload, or integration.
A clear owner for the customer relationship and final outcome.
Different capabilities with responsibilities that can be written down.
A reason the collaboration improves speed, quality, or customer control.

Not a useful starting point

A generic request to exchange logos or links.
Undisclosed referral fees or informal resale expectations.
Shared AWS access without a customer-approved responsibility model.
A dependency that leaves the customer unsure who owns support.

Agree on the boundary before work begins.

01
Name the customer outcome
Describe the workload, decision, owner, success measure, and why two organizations are useful to the result.
02
Separate responsibilities
Document who sells, contracts, implements, supports, handles data, requests AWS access, and communicates with the customer.
03
Scope access and information
Share only the context and permissions each party needs, with customer approval and a clear end to access.
04
Review the handoff
Give the customer the source, decisions, ownership map, support path, and next actions without creating an informal dependency.

Protect the customer relationship by design.

One visible ownership map

The customer should know who owns the contract, implementation, data, AWS access, support, and final decision at every stage.

Separate access decisions

Each organization receives only the information and permissions required for its own responsibility.

Written commercial terms

Fees, referrals, licensing, support, and public references are agreed before introductions or delivery begin.

Questions before a partnership conversation.

Start with one customer outcome or integration.

A short, specific note is enough to decide whether a partnership conversation is useful.

Discuss a partnership Explore products