You brief an OutSystems partner. Two days later you get a proposal back. It has a timeline, a team structure, a price, and a confident scope.
You didn’t have a two-hour discovery call. Nobody asked about your existing data model. Nobody asked how many environments you’re running or what your deployment process looks like. Nobody asked who owns the platform after the project ends.
The proposal exists because they’ve done projects like yours before and they’re pattern-matching. Maybe they get lucky and the pattern fits. Maybe they don’t and you find out six months in when the estimate is blown and the scope is unravelling.
A fixed proposal after a 30-minute brief isn’t confidence. It’s a red flag.
Why OutSystems is different
Most software projects are scoped around features. OutSystems projects need to be scoped around the platform.
The platform has opinions. O11 and ODC are architecturally different. The way you structure modules affects how you can deploy. The way you model entities affects query performance at scale. The way you handle integrations affects what happens when a third-party API goes down. The way you manage roles affects what you can and can’t do without a full deployment.
A partner who doesn’t understand your existing platform setup — or who assumes a greenfield when you’re not — will build you something that works in isolation and creates problems in production.
Good discovery isn’t about covering themselves. It’s about understanding enough to scope honestly.
What good discovery actually covers
The platform audit
Before any conversation about features, a good partner needs to understand what they’re working with.
O11 or ODC? Which version? What modules exist, how are they structured, and what are the dependency chains? What’s the deployment pipeline — LifeTime, manual, CI/CD? What integrations are live and how are they built — REST consumers, SOAP, custom extensions? What’s the database situation — are there Advanced SQL queries, direct database connections, external databases?
If a partner doesn’t ask these questions in the first conversation, they’re either assuming greenfield or they’re going to discover the answers the hard way after the project starts. Neither is good for you.
The ownership question
Who runs this platform after the project ends?
This matters more than most buyers realise. An OutSystems platform built by a consultancy that then disappears is a liability if nobody internal understands it. A platform built with handover in mind — documented, structured to be maintainable, with your team trained on it — is an asset.
Ask any prospective partner: what does the end of this engagement look like? If the answer is vague, that’s information.
The integration risk map
Every integration is a dependency you don’t control. A good partner will ask about every external system your OutSystems platform touches — not just the ones in scope for this project.
Why? Because integrations interact. A change to how you handle authentication for one system can break another. A new integration that runs on a Timer needs to be designed around your existing Timer load. An API that works fine in development goes down in production and now your error handling matters.
Partners who don’t ask about out-of-scope integrations are scoping in a vacuum.
The data model conversation
This is where most proposals quietly fall apart.
Features are scoped based on screens and workflows. But in OutSystems, the complexity is usually in the data — how entities relate, how queries perform at scale, how you handle multi-tenancy, how you manage historical data without killing performance.
A good partner will ask to see the data model, or ask enough questions to understand it, before they commit to an estimate. If they scope based on screens and workflows alone, they haven’t scoped the hard part.
The non-functional requirements
Load. Concurrent users. Response time expectations. Data retention. Audit trail requirements. Regulatory constraints.
These aren’t nice-to-haves that get addressed later. In OutSystems, architectural decisions made early — entity structure, caching strategy, module boundaries, sync vs async — are expensive to change later. Non-functional requirements need to be on the table in discovery.
If a partner doesn’t raise them, raise them yourself.
The questions worth asking any OutSystems partner
These aren’t trick questions. They’re the questions a serious partner should be able to answer clearly and specifically.
“Walk me through how you’d handle a performance issue in production.”
You want specifics. Service Center, log analysis, slow query identification, the difference between an Aggregate problem and an integration problem. Vague answers about “OutSystems monitoring tools” aren’t specific enough.
“How do you structure modules and why?”
There’s no single right answer — but there should be a considered answer. OWASP layering, service-oriented architecture, the forge component decision framework. If the answer is “it depends on the project” without any further elaboration, press harder.
“What’s broken in OutSystems and how do you work around it?”
Every platform has limitations. A partner who tells you OutSystems can do everything hasn’t hit the edges yet. The ones who can tell you exactly where the platform is frustrating and how they’ve worked around it — BPT limitations, Timer constraints, the Advanced SQL necessity, ODC’s current gaps — are the ones who’ve actually built production systems on it.
“What does the handover look like?”
Documentation, training, runbook, knowledge transfer sessions. Ask for specifics. Ask to see an example from a previous engagement if they have one.
“What’s your escalation path when something goes wrong in production?”
Not “we have a support contract.” How fast, what SLA, who specifically picks up the phone, what’s the process for a P1 at 2am on a Saturday.
The red flags
A fixed-price proposal with no discovery. Pattern-matched scoping gets pattern-matched results.
No questions about your existing platform. If they’re not curious about what exists, they’re not scoping — they’re quoting.
OutSystems as a selling point, not a constraint. Partners who lead with “OutSystems can build anything fast” without talking about where it’s slow, limited, or expensive are selling you the marketing version of the platform.
Junior developers on an enterprise platform. OutSystems O11 at scale is not a beginner platform. Ask who specifically will be building. Ask for their experience level and what they’ve shipped.
No mention of non-functional requirements. Features without performance, security, and scalability context is half a scope.
Vague handover plans. “We’ll document everything” is not a handover plan. A handover plan has sessions, deliverables, and a timeline.
What a good engagement looks like from the start
Discovery takes time. Not days — but at minimum several structured conversations covering platform audit, integration mapping, data model review, non-functional requirements, and ownership planning.
The output of good discovery isn’t just a scope document. It’s a shared understanding of what exists, what’s being built, what the risks are, and what success looks like after the project ends.
If a partner can produce that after a 30-minute brief, they’re not thorough. They’re overconfident.
The best OutSystems engagements we’ve been part of started slow. The worst ones started with a proposal that looked comprehensive and wasn’t.
The brief is not the discovery. Discovery is the work you do before the work starts.