Flutter + ASP.NET Core: the stack we use when reliability matters more than hype

The short version

• Mobile: Flutter with BLoC state management — one codebase for Android and iOS.
• Web: React with TypeScript for admin dashboards and portals.
• API: ASP.NET Core 8 (Node.js where a project's ecosystem calls for it).
• Data: Microsoft SQL Server with stored procedures; PostgreSQL when a client prefers it.
• AI services: Python with FastAPI, called through the main API.

Why Flutter for mobile

Most of our mobile work is business apps: field data capture, bookings, order management, collection-centre apps for dairy cooperatives. These need to run on low-cost Android phones, work offline, and look the same on iOS for managers. Flutter does that from one codebase with predictable performance, because it draws its own UI rather than wrapping native widgets.

We use the BLoC pattern for state. It is more verbose than some alternatives, but it separates business logic from widgets so cleanly that new developers can find where anything happens, and it is straightforward to test. When a feature genuinely needs native code — a specific Bluetooth weighing scale, for example — we write a small Kotlin or Swift plugin rather than switching the whole app.

Why ASP.NET Core for the API

• Performance: it is one of the fastest mainstream web frameworks, which keeps hosting costs low for clients.
• Long-term support: Microsoft publishes LTS releases with clear support dates, so clients know how long a version is safe.
• Strong typing: request and response models are checked at compile time, and we generate typed clients for Flutter and React from the same contract.
• First-class SQL Server tooling, which matters because our data logic lives in stored procedures.
• Built-in authentication, authorisation policies, rate limiting and health checks.

Why SQL Server and stored procedures

Business systems are mostly about correct, consistent records: orders, stock, payments, attendance, milk collections. A mature relational database with transactions, constraints and a strong query optimiser is the right foundation. Clients in manufacturing and cooperatives often already run SQL Server for accounting or ERP, which makes integration simpler.

We keep SQL inside stored procedures and expose it only through the API — the reasoning is in our post on why the frontend never touches the database.

What chasing the framework of the month costs

Projects built on whatever was trending when they started tend to age the same way: a library that is no longer maintained, a state-management approach the original developer abandoned halfway, and nobody available who knows the combination.

• Hiring: experienced Flutter, React, .NET and SQL developers are available across India; niche stacks are not.
• Upgrades: mainstream tools publish migration guides; abandoned ones leave you stuck on an old version with security issues.
• Handover: clients own their source code, and another competent team should be able to maintain it without us.

When we choose something else

• Node.js instead of .NET when the project is heavily real-time or the client's team already works in JavaScript.
• PostgreSQL instead of SQL Server when licensing cost matters or the client is already on it.
• Fully native Kotlin or Swift when an app depends on platform features Flutter cannot reach well.
• Next.js for public, content-heavy websites where server rendering and SEO matter most.

The point

A stack is a long-term commitment for the client, not a statement about the developer. We pick tools that will still be supported, documented and hireable in five years, and we spend our creativity on the client's problem instead.

Unsure which stack fits your project? Tell us what you are building and we will recommend one, with reasons, on a free 30-minute call.