How a Tiny Team Ships Like a Big One · The Partner Track
What AWS actually funds: a map of the maze
On Tuesday the product track showed how we automated AWS funding checks. This is the companion for humans: the five kinds of money inside the 80+ programs, what each one wants, and the order to pursue them.
On Tuesday the product track told the automation story: every deal in a pipeline checking its own funding eligibility, 39 opportunities and roughly $3.2M surfaced for one customer. The question we got most in reply was not about the automation. It was simpler and a little embarrassed: "Can someone just explain what all these programs are?" Fair. We spent months in that maze before the map settled. This post is the map: not eighty program descriptions, but the five kinds of money behind them, because the programs change names yearly and the kinds don't.
Five kinds of money
The first kind pays for migrations. This is the deepest pool, MAP being the family name everyone hears first: AWS funds a percentage of the work that moves a customer's workload onto their cloud, in stages that mirror the migration (assess, mobilize, migrate). It wants evidence that a real workload is really moving, and it pays partners for making that happen. If your product or services attach to customers mid-migration, this is the money your deals are swimming next to.
The second kind pays to remove risk from a decision: proof-of-concept and pilot funding, POC and its siblings. Smaller checks, faster process, aimed at the moment a customer is unsure. AWS is buying down the customer's hesitation, and your demo is the instrument. The trap here is scale: POC money funds experiments, and a partner who strings together POC after POC without conversions will find the tap closes.
The third kind pays for your own capability: the programs that subsidize certifications, competency attainment, practice-building, MPOP-style partner development. This is the category we overdrew from once, and the rule from that post applies double here, because the artifacts are about you, not a deal: only take capability money for capabilities you were building anyway.
The fourth kind pays for demand: MDF, marketing development funds, co-funded campaigns and events. It reimburses, slowly and with paperwork, and it rewards partners who already know what marketing they'd run. MDF-shaped money spent on marketing you wouldn't otherwise do fails the say-no test the same way capability money does.
The fifth kind isn't a check at all: credits and discounts, your own AWS bill made smaller, promotional credits for your customers' first workloads. It's the least glamorous and the most certain, which is exactly why it's worth collecting early while the bigger applications grind.
The order matters, and it's the same order as the value: migration and POC money attach to deals, so they compound your pipeline; capability, MDF, and credits attach to you, so they're worth exactly their face value. Deal-attached money first. Always.
Real numbers
- 80+ programs, 5 kinds of money. The kinds are stable; learn those, look up the programs.
- 39 opportunities ≈ $3.2M in one pipeline, nearly all of it deal-attached (kinds one and two) - the automation post's receipts, seen through this map.
- 4 program families supported in our product, all deal-attached, chosen by expected value.
- 2 kinds (capability, MDF) where the say-no test kills most applications, in our experience including our own.
Where the humans sit
The map tells you where money is; only a human on the deal knows whether reaching for it helps or hurts. Funding applications introduce AWS process into a customer's timeline, and there are deals, fast ones, competitive ones, where the right call is to skip free money because the calendar is worth more. That judgment doesn't automate, which is why every funding finding in our product ends at a person who can see the whole deal, and why submission stays role-gated even after the map and the checking are machine work.
Steal this
Classify before you apply: for each program someone proposes, name its kind first, because the kind predicts the paperwork, the timeline, and whether the money compounds. Chase deal-attached money (migration, POC) as a pipeline motion; treat capability and MDF money as discounts on plans you already had, never as plans; collect credits early because they're certain. That prioritization is most of what our eligibility engine encodes, and the part that fits in a paragraph you just read.
This track returns whenever the partnership gives us something worth writing about. Next week on the build track: we pointed the agents at ourselves. Then the product track continues with what a bank-grade AI governance review actually asks.
This post is part of the partner track of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.