Why si should not build your simple apps

Why System Integrators Shouldn't Build Your Simple Low-Code Apps [Do This Instead]

Team Kissflow

Updated on 14 Oct 2025 5 min read

Here's a conversation I've had at least a dozen times with CIOs:

"We invested in a low-code platform to move faster. But our SI partner is still taking months to build simple apps, and the costs haven't changed. What are we doing wrong?"

The answer is uncomfortable: You're not doing anything wrong. You're just asking the wrong people to do the job.

System Integrators aren't failing at low-code because they lack technical capability. They're failing because building simple apps doesn't align with their business model, their expertise, or their economics. And forcing that fit is costing you time, money, and the very agility you bought low-code platforms to achieve.

Let's unpack why this mismatch exists and what to do about it.

The fundamental economics problem

SI developers don't work cheap. And they shouldn't. These are professionals who architect complex enterprise transformations, manage multi-million dollar implementations, and navigate the intricate dependencies of legacy system migrations.

Their expertise commands premium rates because the problems they solve are premium problems.

But here's where the math breaks down: When you assign an SI developer to build a simple expense approval workflow or a basic request tracking app, you're paying enterprise transformation rates for work that doesn't require enterprise transformation expertise.

According to Deloitte's 2024 Global Outsourcing Survey, organizations are increasingly scrutinizing the ROI of traditional SI engagements, particularly for smaller-scale projects where the cost structure doesn't match the complexity.

Think about it this way: You wouldn't hire a structural engineer to hang a picture frame. Not because they couldn't do it, but because it's an absurd use of specialized expertise and budget.

The same principle applies here.

The expertise mismatch

SI developers are trained to think in terms of scalability, integration complexity, and enterprise architecture. They approach problems through frameworks like TOGAF or Zachman. They consider disaster recovery, multi-region deployment, and compliance across jurisdictions.

These are valuable skills when you're building mission-critical systems that need to handle millions of transactions or integrate with dozens of enterprise platforms.

But when the requirement is a department-level workflow that five people will use? That architectural mindset becomes overhead, not value.

Simple apps thrive on speed and iteration. They need someone who understands the business context, can build quickly, test with real users, and refine based on feedback. The person who runs the procurement process doesn't need a 40-page technical design document. They need their approval workflow working by Friday.

Gartner research indicates that by 2026, developers outside formal IT departments will account for at least 80% of the user base for low-code development tools. That's not because IT professionals can't use these tools. It's because the economics and use cases don't justify it.

The project size problem

SI business models are built around substantial engagements. They need projects large enough to justify the overhead of contracts, project management, requirements gathering, sprint planning, and all the governance that comes with enterprise development.

Their profitability depends on billing multiple team members across extended timelines. A project that takes three months with a team of four is economically viable. A project that should take three days with one person? That doesn't work in their model.

So what happens? Simple projects get inflated to fit the SI process. A basic workflow app that a business user could build in a week gets routed through the full enterprise development lifecycle: requirements workshops, design reviews, development sprints, QA cycles, change control boards.

You end up with a three-month timeline and a five-figure invoice for something that didn't need either.

The low-code platform you bought to increase agility becomes just another development environment running at traditional speeds and costs.

The priority challenge

Even when SIs accept smaller low-code projects, they face an internal prioritization problem.

Their senior developers are always needed on the big, complex, high-value engagements. The multi-year ERP implementation. The customer-facing platform rebuild. The cloud migration project.

Simple low-code apps naturally get assigned to junior developers or pushed to the bottom of the priority stack. Not out of negligence, but because resource allocation follows revenue and strategic importance.

The result? Your simple app request sits in a queue behind projects that genuinely need that level of expertise. When it finally gets attention, it's often from someone learning the low-code platform, which defeats the entire purpose of using low-code in the first place.

 

Business Process Reengineering (BPR) – Definition, Steps, and Examples [Guide of 2023]

The opportunity cost nobody talks about

Here's what this mismatch really costs you: Every hour your SI developers spend building simple apps is an hour they're not available for the complex work they're actually suited for.

You're not just overpaying for simple apps. You're also creating bottlenecks in your high-value transformation projects.

Meanwhile, your business teams are waiting for workflow improvements that could have been delivered weeks ago. The agility you promised stakeholders remains theoretical. And your low-code investment isn't delivering the ROI that justified the purchase.

What actually works

The solution isn't to stop using SIs. It's to stop misallocating them.

Reserve SI developers for what they do best. Complex integrations, architectural design, enterprise-grade implementations, systems that require deep technical expertise and formal governance. These are the projects where their premium rates create premium value.

Enable business users for simple apps. The people closest to the work should build the tools they need. Not unsupervised chaos, but structured enablement with appropriate IT oversight. This is what low-code platforms were actually designed for.

Let IT set the guardrails. Security policies, data access controls, integration standards, compliance requirements. IT doesn't need to build every app, but they absolutely need to govern what gets built and how.

Think of it as matching the right tool to the right job. Your SI developers are precision instruments for complex challenges. Low-code platforms with citizen developers are the right solution for the hundreds of simple workflow improvements your organization needs.

The strategic shift

Progressive IT organizations are already making this transition. They're segmenting their application portfolio by complexity and assigning development resources accordingly.

Complex, mission-critical systems? Professional developers, likely with SI support.

Department-level workflow tools? Citizen developers using governed low-code platforms.

Integration and governance layer? IT teams providing the framework that makes both approaches work safely.

This isn't about replacing professional development. It's about optimizing your development capacity across the full spectrum of needs your organization has.

According to Forrester's State of Low-Code Platforms report, organizations that successfully segment their development approaches see 3-5x improvement in application delivery velocity while actually reducing overall development costs.

The questions to ask

If you're evaluating whether to use SI developers for a low-code project, ask yourself:

Does this app require complex integration with legacy systems? If not, it's probably not an SI project.

Will this app serve more than 100 active users? If not, you likely don't need enterprise-grade development.

Does this app handle sensitive data or regulatory requirements that demand specialized expertise? If not, governed citizen development can handle it.

Is the workflow likely to change based on business feedback? If yes, you want the business user who understands the nuances building and refining it.

Will this app take less than two weeks to build? If yes, routing it through an SI creates more overhead than value.

If you answered "no" to most of these questions, you're looking at a citizen developer project, not an SI engagement.

The bottom line

Low-code platforms promised to democratize application development. But that promise only works if you actually let business users build the simple apps they need.

Using SI developers for simple low-code projects isn't just expensive. It's strategically counterproductive. You're misallocating premium resources, creating bottlenecks in your transformation roadmap, and failing to realize the ROI your low-code investment should deliver.

The path forward is clear: Match project complexity to developer expertise. Reserve your SI partners for the complex challenges that genuinely need their skills. Enable your business users to solve their own workflow problems with appropriate governance.

That's not just better economics. It's better strategy.

Ready to optimize your development capacity?

Kissflow helps IT leaders make this transition successfully. Our low-code platform empowers business users to build simple apps while giving IT the governance controls to ensure security, compliance, and standardization across your organization.

Stop paying enterprise development rates for department-level workflow tools. 

Stop overpaying for simple apps.