What We Don't Build

Every studio has a boundary. The ones that do not publish it leave clients to discover it mid-engagement, which is the worst time for everyone.

This is ours. Twelve categories of work we decline, each with the reasoning. The list is a live document; it has changed three times in two years and will change again. When it changes, the revision is noted at the bottom.

The purpose of the list is not to signal that we are selective for the sake of selectivity. The purpose is that the work inside the boundary is work we are genuinely good at. Work outside the boundary is work we would execute competently but not exceptionally — and a client who needs competent execution has more options than a client who needs the specific thing we do at our best.

1. Greenfield SaaS with no AI architecture requirement

If the brief is "build us a SaaS product" and the AI involvement is either absent or cosmetic — an LLM summarising user-generated content, a chatbot on a support page — we are not the right studio. We do not decline this because the work is easy; we decline it because our best work is integrating AI as a first-class architectural layer, and a brief that treats AI as an add-on does not need what we are best at.

The founders who are best served by the studio are the ones where the AI is not optional — where the product cannot exist without the orchestration layer, where the AI is doing the work, not decorating it.

2. Agencies, resellers, and white-label arrangements

We do not build for intermediaries who will represent the work as theirs to a downstream client. The arrangement creates two problems: scope drift without clear authorship, and an accountability gap between the person who signed the brief and the person who will use the product. Both are solvable in theory; neither is worth solving in practice when there are direct-client engagements available.

If an agency has a client who needs what we do, the right path is to introduce the client directly, not to intermediary the relationship. We make introductions freely.

3. Projects requiring regulatory compliance as a deliverable

If the brief includes language like "must comply with [specific regulation]" and the compliance work is part of the studio's scope — not the client's — we decline. Compliance work requires domain-specific expertise that varies by regulation, jurisdiction, and the specific compliance posture of the client. We are not a compliance consultancy. We can build systems that are designed to support compliance; we cannot certify compliance, and we will not scope work that implies we are doing so.

The line is: if the client has a compliance team that defines the requirements and our job is to implement them, we can discuss it. If we are expected to define the requirements, we are not the right resource.

4. Consumer applications targeting non-technical general audiences

We build for founders, operators, and technical users. Products that need to acquire and retain general-public consumers at scale require a set of skills — growth, localisation, consumer UX at high volume — that are not our strength. Our UI work is clean and functional; it is not the consumer-grade polish that wins app-store rankings and reduces churn in a market where users have no professional context for evaluating quality.

5. Hardware-integrated products where the software is secondary

If the brief is primarily about a physical device and the software is an interface to it, we are not the right studio. We do not have hardware engineering capacity, and we will not build software for a hardware project without the hardware certainty that software assumptions are grounded in. Briefs that arrive with "we'll handle the hardware, you handle the app" consistently underestimate how much the hardware uncertainty flows into the software scope.

6. Projects with procurement-locked vendor requirements

If the brief includes "we must use [specific vendor] for [core function]" and the vendor constraint is non-negotiable, we need to understand the constraint before proceeding. Some vendor constraints are fine — we use Supabase, Cloudflare, Anthropic; we are not neutral-vendor. But vendor lock-in that restricts architectural decisions in ways that prevent us from building what the brief requires is a blocker. We will not design a system that we know is wrong because the client's procurement approved a vendor that makes it wrong.

7. Long-running maintenance retainers without a delivery anchor

A retainer for "ongoing improvements" with no delivery attached to it is not a product engagement. Every engagement starts with a delivery — something specific that ships — and retainers are for post-delivery stewardship of a system we built or understand. A retainer attached to nothing is a relationship where the incentives are misaligned from the start: we are paid for presence rather than for outcomes, and there is no moment at which either side can say whether it worked.

The objection is the missing delivery anchor, not the billing model. Where scope genuinely cannot be defined up front we will work time-and-materials and say so, rather than quote a fixed price we would have to defend by narrowing the work.

8. "Explore AI possibilities" consulting without a product commitment

If the brief is "help us understand how AI could apply to our business" and there is no commitment to building anything, the work is advisory consulting, not product delivery. We are not a consulting firm in that sense. We will not charge for slides that describe an AI strategy. The Discovery engagement gets close to this territory — it ends with a plan, not production code — but the Discovery requires a specific product problem that the founder has decided to solve, not an open-ended horizon scan.

9. Competitive intelligence or market research products

Products whose primary value is gathering, processing, and presenting data about competitors, market prices, or third-party systems involve a category of legal and ethical complexity that we do not want to absorb into our project scope. The line between market research and scraping is blurry and jurisdiction-dependent. We would rather not navigate it.

10. Products that automate human judgment in regulated high-stakes domains

Clinical diagnosis, legal advice, financial planning advice, safety-critical industrial systems — any domain where the automation of human judgment carries regulatory and ethical obligations that a project studio cannot adequately scope. We can build systems that assist professionals in these domains; we will not build systems that replace their judgment. The distinction is real but often fuzzy in the brief. If the fuzziness is present, we will ask about it directly before proceeding.

11. Requests that arrive without a named problem

"We want to build a platform" is not a brief. A brief has a problem, a user who has the problem, and some evidence that the problem is real. We do not start from scratch on the discovery of whether there is a problem worth solving. The studio's Discovery engagement assumes the founder has already done that work; it validates and plans from there. A brief that has not done the foundational discovery is a brief for a different kind of service than we offer.

12. Projects requiring the studio's name not to be disclosed

We work under our own name. Project credits, case studies, references — we disclose them. If the engagement requires that the studio's involvement be concealed from third parties (investors, acquirers, end users), we decline. Stealth projects where the product itself is not yet public are fine; projects where the studio's involvement must be hidden are not. The asymmetry is deliberate: we will protect a client's product confidentiality, but we will not protect a secret that requires us to misrepresent our work.

The referral practice

When a brief falls into one of these categories and we know who the right resource is, the first reply includes a referral. Not after a long intake process — in the first reply.

The referral is specific. "You should talk to [name/studio] because [specific reason]." Not "try searching for agencies that do X." We maintain relationships with studios and specialists across the categories we decline precisely because the referral is only useful if it is credible.

What changed and when

2026-03-12 — Added category 11 (no named problem). Previously we were declining these briefs individually without a policy. Formalising the category reduced the number of intake calls that ended with "we can't start from that point."

2026-01-20 — Refined category 3 (compliance) to distinguish implementation from certification. The original version was too broad and was declining briefs where the client had a compliance team and we were building to their spec. The refined version accepts those briefs.

2025-11-08 — Added category 12 (name not to be disclosed). The first version of this list did not address it explicitly. A small number of inbound briefs in Q3 2025 made clear a policy was needed.

FAQ

Why does Rapoport Studio publish what it declines?

Because the boundary is part of the service. A founder who reads this list before contacting the studio arrives with calibrated expectations and less wasted time. A founder who reads it after a declined brief arrives with the same outcome but more friction. Publishing the list moves friction earlier in the process, where it is cheaper for both sides.

Does the studio ever make exceptions to its decline list?

Rarely, and only when the brief reframes the work in a way that changes which category it falls into. The categories are not arbitrary preferences — they are derived from where the studio produces its best work and where it does not. An exception that moves us outside our best-work zone is not a service to the client; it is a way of charging for mediocrity.

What kind of projects does Rapoport Studio actually take?

Digital platforms that require an AI orchestration layer, products that coordinate multiple agents or AI capabilities in production, and founders who are building systems where the AI is architecture — not a chatbot grafted onto an existing product. The Discovery engagement is the starting point for understanding fit.

If the studio declines my brief, does it refer me elsewhere?

When the work fits a pattern we recognize and we know studios or specialists who do it well, yes. The referral comes in the first reply, not at the end of a long intake process. Our network page lists communities and specialists the studio has direct relationships with.

Does the studio take on early-stage projects with no technical co-founder?

Only through the Discovery engagement, which produces a validated technical plan rather than production code. The plan gives the founder enough specificity to recruit a technical co-founder or evaluate other studios. We do not substitute for a technical co-founder on an ongoing basis — that is a different relationship with different incentives than a project studio.

The list is available to quote, share, or adapt. If you are building a studio and want to document your own boundary, we think publishing it is worth the vulnerability. The founders who are a bad fit for your work will find someone better for them, faster. The founders who are a good fit will have higher confidence that you know what you are doing.

Both outcomes are good ones.