Low-code or pro-code? Ask a different question
“Should we build this in low-code or write it in Python?” comes up on almost every project. It’s usually the wrong first question.
The better one is: who will look after this in a year?
A rough guide
| If… | Lean towards |
|---|---|
| The business team will own and tweak it | Low-code |
| It needs to sit inside existing Microsoft 365 workflows | Low-code |
| It needs custom orchestration or unusual integrations | Pro-code |
| You have engineers who will maintain it | Pro-code |
| You’re not sure yet | Start low-code, keep the logic portable |
Portability is the hedge
Whichever you pick, keep the important parts outside the tool: prompts in version control, business rules documented, integrations behind APIs you control. Then switching later is a migration, not a rewrite.
The cost nobody budgets for
The build is a one-off. Support, licensing changes and the next platform update aren’t. Factor in the people, not just the platform.