Building and Certifying a Make App: Process, Timeline, and Cost for B2B SaaS

If your B2B SaaS has an API but isn’t on Make, thousands of automation builders are quietly picking your competitors instead. Make has over 500,000+ organizations actively building automations, and the apps already on the platform get pulled into scenarios without anyone asking your sales team.

This guide walks through what it takes to build and certify a Make app: what to scope in or out, how long it takes, what it costs, and how to ship faster. Make, Zapier, and n8n share most of the same basics — what differs is the specifics: review processes, SDKs, certification mechanics, monetization paths. We’re covering Make here. Dedicated guides for Zapier and n8n are coming in the following weeks — stay tuned.

---

Why publish your SaaS on Make in the first place?

Distribution. Make’s user base spans operations teams, agencies, technical founders, and AI builders — people who pick tools that already plug into their stack. If your SaaS isn’t in their app picker, they’ll choose a competitor that is.

There’s also a sales argument. Not every customer justifies a custom API integration. Smaller deals can self-serve through your Make app and connect to thousands of other tools without your engineering team writing a line of code. Your team stays on product; your smaller customers still ship. We’ve covered the broader case for integrations as a revenue driver elsewhere — Make is one of the fastest channels to put that into practice.

The newer angle is AI, and it matters more than most teams realize. Make now supports building scenarios with LLMs — agents using Claude, GPT, and others can compose flows by reading app metadata and your public documentation. Two effects compound here:

1. AI agents will recommend your app if it is publicly accessible. When someone asks an AI to build a scenario involving your category, the agent picks from apps available on Make. If you’re not on the platform, you’re not recommended.
2. AI lowers the barrier to building integrations for technical users. Instead of reading docs and writing code, they describe what they want and the AI assembles the scenario — but only if it can actually read your docs to know what your API does. Well-structured docs let the agent pick the right module and ship a working scenario. Docs behind a login or buried in PDFs cause the agent to fail, hallucinate, or pick a competitor with better-documented modules.

Treat AI visibility and clean public documentation as launch requirements, not future problems.

What exactly is a Make app, and how is it different from an integration?

A Make app — sometimes called a connector — is a published package that lives inside Make’s drag-and-drop scenario builder. It exposes your SaaS as a set of building blocks that Make users can drop onto a canvas and chain with thousands of other apps.

That’s different from a custom API integration. A custom integration connects your SaaS to one specific customer’s system. A Make app exposes your API to every Make user simultaneously — same building blocks, many scenarios, no per-customer engineering work. You build once; every Make user benefits.

The pieces of a Make app, in plain English:

• Actions — things users can do with your API: create a record, update a record, send a message.
• Searches — ways to look something up: find a customer by email, list recent orders.
• Triggers — what kicks off a scenario. Two flavors: instant triggers, where your app pings Make the moment something happens, and scheduled triggers, where Make checks your API on a schedule (every minute, hour, day) for changes.
• Login — how a user links their account. Either a simple API key (paste a key) or a “log in with” button (OAuth).
• Smart dropdowns — when a user picks something inside your module, the dropdown is populated live from your API (a list of their projects, channels, customers).

Make’s Custom Apps documentation covers each in more technical depth.

Private, Community, or Public app — which path fits your strategy?

Make offers three publishing paths.

Private apps stay inside your own Make organization. No review needed, only your team and invited collaborators can see/use them. Useful for testing, internal automations, or staging before public release.

Community apps publish through the Make Apps Marketplace community section. They skip Make’s formal review (faster to ship) and (the part most SaaS teams miss) you can charge users for access individually, outside Make. You share an invite link, handle billing on your side, and users pay you plus Make’s standard platform fee. Good fit for niche power-user features, premium connector modules, or monetizing the connector itself before you build native pricing.

Public (Verified) apps go through Make’s review process and land in the main app library. They’re free for users — Make charges customers for the operations they consume, but your app itself doesn’t add cost. Two wins here: reach (every Make user can discover and connect your app), and a benefit most teams underestimate — self-service customers who would otherwise ping your team for a custom integration can now connect themselves. Less custom-integration burden, more self-serve adoption. You don’t earn directly from the app; the wins are top-of-funnel and operational.

There’s no single right path, and the two published paths often complement each other. Two common patterns:

• Ship a public app first for reach, then add a community variant later for premium modules.
• The reverse also works — build a community app first to cover your existing customer base and their specific integrations, then once the app is production-mature, publish a public version to expand to new users.

Pick based on whether your priority is direct monetization, broad reach, or supporting your existing customers first.

For the official breakdown of how Make classifies apps, see Make’s introduction to apps.

What should you actually publish in your Make app — and what to ignore?

Build for the workflows users will run repeatedly, not your full API surface.

A Make scenario is a recurring automation. It fires on a trigger (event or schedule) and runs steps before and after, often chaining your app to a CRM, database, or notification tool. The actions and triggers worth building are the ones that fit that pattern: creating records, updating records, watching for new records, searching for records, and reacting to events.

Modules not worth building: one-off admin actions like “change user password,” “delete account,” or “rotate API key.” Nobody automates those on a schedule. They belong in your dashboard, not your Make app.

A best practice we recommend on every project: ship a generic “Make an API call” module alongside your structured modules. It lets advanced users hit any endpoint of your API directly from Make. You build the login and base setup once; the user covers the long tail of endpoints you didn’t model. You get coverage without building every action, and power users get flexibility without filing feature requests.

When picking which structured modules to build, look at your API analytics: which endpoints are hit most, which support webhooks, which return data users would want to filter on. Build for those first.

How long does it take to build a Make app?

Hours to weeks, depending on scope.

A team that’s done this before can ship a single basic action against a documented REST API in under a day. A full multi-module app with secure login, instant triggers, smart dropdowns, and clean error handling across 8–10 modules takes 1–4 weeks of focused engineering.

Besides API complexity, three things drive build time: module count (more modules, more time, in a roughly linear way), login complexity (a simple API key is fast; full OAuth with refresh tokens takes meaningful setup), and trigger type (instant triggers need backend coordination on your side; scheduled triggers don’t).

How long does Make’s certification process actually take?

Plan for 4–6 weeks from submission to public listing for a verified app, sometimes longer if you hit rejection cycles.

The review queue is the fixed bottleneck. You can’t accelerate Make’s reviewers, but you can reduce the number of review rounds by submitting clean the first time. Common rejections: incomplete metadata, login flows that fail on first connect, modules whose behavior doesn’t match the documentation, missing privacy policy URL, naming convention violations, error handling that returns raw HTTP errors instead of useful messages, and modules that fail when API rate limits hit.

Community apps skip the formal review path entirely — there’s no fixed certification timeline, just a publication step. That’s part of why teams optimizing for speed-to-market sometimes ship community first and migrate to public later.

How do you speed up Make app certification?

Two levers.

The first is technical: ship submission-ready on the first try. That means login flows that work on first connect, every action and trigger tested against live API responses, error handling that surfaces useful messages, complete metadata, a privacy policy URL that resolves, and naming that matches Make’s conventions. Most rejection cycles trace back to one of those.

The second is to work with an integration partner who already has direct contact with Make’s review team. We’ve been through enough Make app submissions to know the rejection patterns before they land — what reviewers will flag, what compliance language they expect, how to phrase module descriptions so review goes through cleanly. When something does need clarification, having a direct line to the review team collapses the back-and-forth from weeks to days. If certification timeline matters to your launch plan, hiring an experienced partner is the fastest way to compress it.

You can ship a Make app without an experienced partner, but you might hit more review cycles, and each one adds a week or two to your timeline. The decision-making framework for outsourcing this kind of work is covered in our guide on choosing an API integration partner.

How much does it cost to build and publish a Make app?

For a production-grade Make app including build, testing, and certification, expect EUR 3,000–15,000.

The variability comes from how many actions and triggers you need, login complexity (a simple API key sits at the bottom of the range; full OAuth login adds work), instant triggers (which need backend coordination on your side), smart dropdowns, and how much pagination, rate limiting, and error mapping the underlying API requires. App quality depends heavily on how clean your API is to begin with — well-documented REST endpoints with consistent error responses ship faster than APIs with inconsistent shapes.

For context: building a Make app and building a custom API integration tend to land in roughly the same price range. The work is similar — there are pieces you build for Make that you wouldn’t for a generic API integration (module schemas, smart dropdowns, certification artifacts) and pieces you’d build for an API integration that aren’t relevant for Make. For a partner who’s done both, the numbers hold. If your in-house team knows API integrations but is learning Make for the first time, expect the upper end of the range plus a learning curve.

That range can be more concise after the initial scoping call. We come back with a fixed quote, a module plan, and a timeline within 48 hours of seeing your API docs.

What happens after your Make app goes live?

Apps need maintenance. Your API will change. Make will update its requirements. Users will request new modules. Instant triggers will break in edge cases nobody tested.

When you decide who builds the app, make the post-launch plan part of the contract. Two reasonable options:

1. Ongoing maintenance with the partner. Recertification cycles, new module additions, login scope updates, and bug fixes go through the same team. Faster turnaround, no knowledge transfer cost.
2. Thorough handover documentation. If you’re taking the app in-house after launch, demand a complete handover: source repo with build instructions, certification artifacts, a runbook for the Make review process, login credentials and rotation procedure, and a contact log for the Make review team. Without this, the first time something breaks you’ll be reverse-engineering the build from scratch.

Either path works. The path that doesn’t work is “we’ll figure it out later.” That’s how Make apps go stale, accumulate user complaints, and eventually drift away from the underlying API.

The AI angle from earlier matters here too: keep your public API docs current and crawlable as your app evolves. AI agents building Make scenarios will read those docs and route around your app if they go stale.

---