This blog post is AI-Assisted Content: Written by humans with a helping hand.
The most expensive mistake you can make on a Sigma App project isn’t a technical one. It’s starting to build before you’ve clearly defined what you’re building. I’ve seen projects double in scope mid build because the initial conversation used “Sigma App” to mean something different than what the builder heard. I’ve seen “a few weeks” projects turn into “several months” projects because one input requirement, casually mentioned in a kickoff call, turned out to require a completely different architecture.
The good news: Most of this is preventable with a short conversation upfront. Here’s how to have it.
Step One: Is It a Dashboard or an App?
This is the most important question and the most commonly skipped one.
- Dashboard: The user is a viewer. They look at data, filter it, drill down. Data flows one direction, from the warehouse to the screen. These are relatively straightforward to scope.
- Sigma App: The user is embedded in the process. They enter information, submit things, trigger workflows, make approvals. Data flows both directions. These scope differently and build differently.
- Hybrid: The app includes both. Users view dashboards and interact with the data: Submitting, flagging or triggering workflows from the same interface. These are still Sigma Apps, but the dashboard components need to be scoped separately. Don’t let them sneak in mid-build.
Get this distinction right before you scope anything else.
Step Two: Break It Into Four Components
Once you’ve confirmed it’s a Sigma App, every app you’ll build has the same four components. Scope each one separately:
- Input: Where and how do users enter data? A simple form? A table they fill row by row? Multiple linked tables where one entry drives another? Every input needs a destination, and how that data gets written back to the warehouse affects the architecture.
- Logic: What rules run on the inputs? Calculations, validations, workflow steps, approvals? Does logic run automatically or does a user trigger it?
- Views: What does each type of user see? Are there multiple screens? A submission view vs. an approval view vs. a summary view?
- Roles: Who uses this? Submitters? Approvers? Managers with read only access? Admins who can override?
Each component adds scope. Two roles is more work than one. Three views is more work than one. The complexity compounds when they interact, when the logic differs by role, or when views change based on workflow state.
Step Three: Match It to an Archetype
Most Sigma Apps fall into one of three tiers. Once you recognize which one you’re dealing with, the scope estimate follows naturally.
Tier 1: Simple (1 to 2 weeks)
- A form or log where users enter independent rows
- A dashboard where users can flag or annotate a few values
Tier 2: Medium (3 to 6 weeks)
- Two or more roles with different permissions and views
- A submission and approval workflow (someone submits, someone else approves)
- A what if model where users enter assumptions and see computed outputs
- Multiple users each filling their own section that rolls up into a combined view
Tier 3: Complex (2+ months)
- Budget or planning tools that replace Excel files, especially with hierarchy (departments → divisions → company)
- Distribution or allocation grids where entries must sum to a total
- Any pattern where what you enter in one section changes the rows or shape of another section
*For medium and complex apps, build training and handover into the scope. As users move from Excel processes into an app experience, ad-hoc support follows. Most of these requests are often training questions, not bugs. If you don’t account for it upfront, it shows up as unplanned time at the end.
Five Questions to Ask Before You Start
These few questions will tell you most of what you need to know:
- What is this replacing today? A spreadsheet, an email chain, a manual process in another system? The answer tells you what behavior the user expects and what “good” looks like to them.
- Who enters data, and who reads it? If different types of users do different things, you have multiple roles. Multiple roles mean multiple views. That’s scope.
- Is there an approval step? If anyone reviews, approves or rejects something another person submitted, you have a state machine. That’s a significantly different build than a simple form.
- Is this one row at a time, or does one entry expand into many? Sigma’s writeback is built for row by row input. If a single user action needs to generate multiple output rows, like selecting a set of items that each get their own record, that’s a different architecture. Flag it early.
- What has to be in version one, and what can wait? Get explicit agreement on this. Every feature that moves into V1 is scope. Every feature that moves to V2 is a later conversation.
Scoping Is the Architectural Decision
There’s a temptation to treat scoping as a formality, a box to check before the real work starts. It’s not. Scoping is where you decide what you’re building, which determines the architecture, which determines whether the project is weeks or months.
Document inputs, map the logic, confirm the roles, bound V1 before you start building. That project looks a lot different than the one that grows by requirement in real time.
The conversation takes an hour. Getting it wrong costs much more than that.
