By Raf CEO

If you run a small or mid-size business and you need a custom app — a client portal, an internal tool, a booking flow, a reporting dashboard — someone will eventually ask: “What stack should we use?”

That question is easy to overcomplicate. Framework lists grow every year. Opinions are loud. For most SMB projects, the useful answer is quieter: pick a stack your team (or your partner) can support for years, that fits the problem you actually have, and that does not paint you into a corner when the business changes.

This guide is for owners and operations managers who will approve the choice, not for people collecting framework badges.

Start with the job, not the logo

Before anyone names React, .NET, Python or WordPress, write down the job in one page:

  • Who uses the app (staff, customers, both)?
  • What must it do in the first ninety days?
  • What systems does it already need to talk to (email, CRM, accounting, payments, files)?
  • Where will it live (your cloud account, a shared host, on-prem)?
  • Who will change copy, add a field or reset a user after launch?

If you cannot answer those, the stack debate is premature. A clear job description filters half the options without a single benchmark chart.

The five questions that matter more than trends

1. Who will maintain it?

A beautiful stack that only one contractor on earth can touch is a risk. Prefer tools your future hires, freelancers or partners can find. Popular does not mean best — but orphaned does mean expensive.

Ask your delivery team: “If you were unavailable for a month, who else could ship a safe fix?” Their answer tells you more than a feature matrix.

2. How often will the product change?

Marketing sites and content-heavy tools benefit from editors that non-developers can use (WordPress is still a strong fit there). Product-style apps with complex workflows often need a proper application framework (for example React or Next.js on the front, and Node.js, .NET, Python or PHP/Laravel on the back).

If non-technical staff must change pages weekly, do not bury content inside a developer-only deploy. If the app is mostly workflows and permissions, do not stretch a CMS into a product it was not meant to be.

3. What do you already run?

Reuse beats novelty. If your office already lives in Microsoft tooling, .NET and Azure may reduce friction. If your site is already WordPress, a plugin or a small Laravel/Node service beside it may be enough. If your team already ships React components, starting over in an unfamiliar UI framework adds cost for little gain.

Greenfield is fun in demos. Brownfield is how most SMB software actually ships.

4. What are the integration edges?

List every system the app must call. APIs, file drops, SSO, webhooks, databases. The hard part of SMB software is rarely the homepage — it is the brittle join between tools. Choose a stack with solid HTTP, queue and database libraries, and a team that has done integrations before.

Databases matter here too. SQL Server, PostgreSQL and MySQL are all fine for most SMB apps; MongoDB can fit document-shaped data. The wrong choice is picking a database because it sounded modern, then discovering your reporting tools do not speak to it cleanly.

5. How will you deploy and roll back?

Cloud and DevOps are part of the stack, not an afterthought. Azure and AWS both work. Docker and a simple CI/CD pipeline make releases boring — which is what you want. Agree on backups and a rollback path before the first production push. A stack with no safe release process is incomplete.

A simple map for common SMB app types

These are starting points, not rules:

  • Content site or brochure with forms: WordPress (or a static/Next.js site if developers own all edits).
  • Online store: Shopify or WooCommerce first; custom storefront later if catalog and checkout truly outgrow them.
  • Internal admin tool: .NET, Python (Django/FastAPI), PHP/Laravel or Node.js with a straightforward UI.
  • Customer portal with rich UI: React or Next.js front end plus a sober API layer.
  • Mobile companion app: React Native or Flutter when one codebase must serve iOS and Android; native when you need deep platform features and have the budget.
  • Automation and assistants beside the app: keep AI features as a clear module with permissions and review steps, not a mystery box mixed into core billing logic.

“And more” is fine. The point is fit, not collecting every logo on a slide.

What to ignore (for now)

  • Microservices “because scale.” Most SMB apps do well as a modular monolith until traffic or team size says otherwise.
  • Rewrites of working systems to chase a trend.
  • Vendor lock-in fear that leads to building everything yourself. Managed email, auth or payments are often the rational choice.
  • Invented case studies and vanity benchmarks. Ask for a plan, a risk list and a maintenance story instead.

A decision sequence you can run in one workshop

1. Write the one-page job description.

2. List must-integrate systems and who maintains them.

3. Choose CMS vs application framework based on who edits what.

4. Pick language/ecosystem based on maintainer availability and existing skills.

5. Pick hosting (Azure, AWS or current host) and a backup/rollback path.

6. Write a short “why we chose this” note so future you remembers.

DNN Direct works across many of these stacks — React, Next.js, Vue, Angular, Node.js, Python, PHP/Laravel, WordPress, .NET/C#, Java, mobile, and more — so our bias is toward the fit for your office, not a single hammer. If you want a second opinion on a stack shortlist, bring the one-page job description to a consultation and we will tell you honestly what we would pick and why.

Bottom line

The best SMB tech stack is the one your business can operate on a quiet Tuesday six months from now. Choose for the job, the maintainers, the integrations and the release path. Leave room to grow. Ignore the noise that does not change those four things.