In 2026, software is no longer just a tool for SMB and mid-market companies — it is the central lever for differentiation, scaling and operational efficiency. Anyone who casts a business process into software can measure it precisely, improve it incrementally, and scale it without adding headcount. Anyone running that process through Excel sheets, email ping-pong or verbal handovers pays for friction every day. At the same time, the question "Which software for which process?" has become more demanding: between ready-made SaaS products, low-code platforms and individual custom software, there are now real choices with very different cost, risk and speed profiles. This guide shows when each option is the right one, which tech stack carries reliably in 2026, what professional architecture looks like and what the realistic costs are.
Why custom software development is a competitive advantage in 2026
The SMB and mid-market segment in DACH has predominantly relied on off-the-shelf software over the past ten years — and that was usually the right call. Accounting, classic CRM and core ERP functions are standardized because they work similarly everywhere. But that creates a problem: when all of your competitors run on the same off-the-shelf software, software can no longer be a differentiator. Competitive advantages today emerge where you have processes that your competition does not — and mapping those rarely fits off-the-shelf software.
Three drivers make custom software more economically attractive in 2026 than five years ago. First, falling build costs: modern frameworks like Next.js, SvelteKit and Nuxt 4 plus established component libraries (shadcn/ui, Mantine, Radix) reduce implementation effort by 40 to 60 percent compared with 2020. Second, AI assistance: developer tools like Cursor, GitHub Copilot and Claude Code now write the boilerplate code that used to consume 30 percent of build time. Third, rising off-the-shelf costs: SaaS licenses have gone up 25 to 60 percent over the past three years, with features simultaneously pushed into higher tiers. Above a certain annual license spend, building in-house becomes more economical than ever-higher rental fees.
In practice that means: anyone with a business process that is truly theirs should honestly calculate in 2026 whether ongoing customization of an off-the-shelf solution still pencils out — or whether a focused in-house build with a clear MVP scope is the better investment for the next ten years.
Custom software vs off-the-shelf vs low-code — a decision framework
Three options are on the table today, each with a clear usage profile. The decision is not a matter of belief but hangs on a few objective criteria.
Off-the-shelf software (SaaS) is right when the process can adapt to established software, there is no differentiation potential in the process, fast availability matters more than a perfect fit, and the annual license volume stays below roughly EUR 30,000. Classic fields: accounting (DATEV, Sage, Lexware), classic CRM (HubSpot, Pipedrive, Salesforce Starter), project management (Asana, Linear, Jira), HR master data (Personio, BambooHR).
Low-code platforms (Microsoft Power Platform, Mendix, OutSystems, Retool, Bubble) are right when the use case is internal tools of manageable complexity, the team has a technically savvy power user (citizen developer), and maintainability over five to seven years is acceptable. Caveat: low-code feels faster up front but quickly becomes unmaintainable as logic grows, and creates vendor lock-in. Often the right choice for form-heavy internal workflows, rarely for customer-facing products.
Custom software is right when the process is your differentiator, no suitable off-the-shelf solution exists, several hundred users or high demands on UX, performance or compliance apply, or the annual license bill for an off-the-shelf solution exceeds EUR 50,000 and keeps growing. Classic fields: vertical industry platforms, customer portals with their own identity, B2B marketplaces, data-intensive control systems, regulated applications with an individual compliance profile.
The most common mistake in practice: companies pick an off-the-shelf solution, adapt it with customization, end up paying 60 to 120 percent of the license price in customization costs over the years, and finish with a poorly maintainable bespoke solution dressed up as a standard product. If you can already see during discovery that more than 30 percent of license features will go unused and more than 30 percent need to be added through customization, custom software is usually the more economical choice.
Web applications 2026 — TypeScript, Next.js, Vue, SvelteKit, Tailwind
Web applications are the dominant form of business software in 2026 — ahead of mobile apps, ahead of desktop applications. Three reasons: universal reach without installation, central updates without endpoint roll-out, a unified tech stack between internal administration and external customer portals. The stack question has consolidated over the past few years.
TypeScript as the language is undisputedly the right choice for new builds in 2026. Static type checking, excellent IDE support, broad library availability and a huge talent pool. We only recommend plain JavaScript for very small scripts or legacy code.
Next.js with App Router is the de facto standard for more complex web applications — React-based, server-side rendering, integrated API routes, excellent performance, very broad developer availability. Next.js 16 (Cache Components, Partial Prerendering) delivers the best mix of developer productivity and end-user performance in 2026. Hosting on Vercel or as a standalone build on your own infrastructure.
SvelteKit is the lean alternative for teams that value smaller bundle sizes, simpler reactivity mechanics and less boilerplate. Svelte 5 with Runes has a very tidy programming-model story in 2026. Suitable for mid-sized applications with a small to mid-sized team.
Vue.js with Nuxt 4 remains a valid choice, especially strong in Europe. Lower entry barrier than React, good performance, established ecosystem. Sensible when your team already has Vue experience or when you are sourcing developers in regions where Vue is more widespread than React (France, parts of Eastern Europe).
Tailwind CSS is the established standard for styling in 2026. Utility-first, very productive, combinable with component libraries like shadcn/ui, Radix UI or Headless UI. Classic CSS or CSS-in-JS continue to lose market share.
Our default recommendation for a new SMB or mid-market project in 2026: TypeScript + Next.js (App Router) + Tailwind + shadcn/ui for the UI layer, PostgreSQL + Drizzle ORM for the data layer, Vercel or a classic PaaS for hosting, Vitest and Playwright for tests. With this stack, an experienced team builds a productive MVP in 90 days.
APIs — REST vs GraphQL vs gRPC vs tRPC
The API layer decides how well your application cooperates with other systems, clients and partners. Four styles are relevant in 2026, each with a clear field of use.
REST remains the default for public APIs, partner integrations and simple client-server applications. Advantages: universally understood, excellent tool chain (OpenAPI/Swagger for spec and code generation, Postman/Insomnia for testing, caching via standard HTTP mechanisms). Disadvantages: over-fetching and under-fetching with complex UIs, many endpoints for large data models. The right first choice for 70 percent of all projects.
GraphQL pays off when you serve multiple clients with different data needs (web, mobile, public API) or when over-fetching is a real problem. Apollo Server and Mercurius (for Fastify) are the established server implementations in 2026. Disadvantages: higher complexity in authorization, caching and performance tuning (solve the N+1 problem via DataLoader patterns), steeper learning curve in the team.
gRPC is the right choice for internal service-to-service communication with high throughput and tight latency requirements — Protobuf schema, HTTP/2, native streaming support. Useful in microservice architectures or for real-time data streams. Unsuitable for external APIs because browser support only works through gRPC-Web with a reverse proxy.
tRPC is a pragmatic, newer option for TypeScript monorepos where client and server are developed by the same team. Type safety from database to UI without a separate API spec, without code generation. Very productive for internal tools and small to mid-sized SaaS applications. Unsuitable for cross-language or cross-team interfaces.
Practical rule of thumb: REST for external, tRPC for internal in TypeScript stacks, gRPC for internal service-to-service calls with performance demands, GraphQL only on demonstrable need. Most projects need exactly one API style — not three in parallel.
Mobile — native iOS/Android vs React Native vs Flutter vs Capacitor
Mobile apps are rarely the default in 2026 — most SMB and mid-market requirements can be covered with a Progressive Web App (PWA). But if you really need an app, four options are on the table.
Native (Swift for iOS, Kotlin for Android) is the choice when you offer a premium consumer experience, frequently access current platform APIs (Apple Vision, ARKit, Health, Wallet), or need hardware-close features (Bluetooth Low Energy, NFC, camera control). Effort: two separate code bases, highest implementation and maintenance overhead, in exchange for the best UX and platform integration.
React Native is the established cross-platform choice for business and B2B apps in 2026. One TypeScript stack, very broad library selection, native modules loadable as needed. With Expo as the framework, initial complexity drops significantly. Reaches 85 to 95 percent of native experience at 50 to 60 percent of the effort compared with two native code bases.
Flutter is Google's cross-platform answer, with its own language (Dart) and its own rendering. Delivers pixel-perfect UIs on iOS and Android, and optionally web and desktop. Advantage: consistent look across platforms, very good performance on animations. Disadvantage: Dart is a niche language, smaller talent pool than React Native, fewer third-party libraries.
Capacitor (Ionic) packs a web application into a native container. Suitable when you already have a web application and want to ship it into the app stores without major rework. UX quality is clearly below native and React Native, but the effort is minimal. Useful for internal tools, information apps or as a bridge to a later real mobile build.
Our recommendation: PWA as default, React Native with Expo on real mobile demand, native only for premium consumer apps or strong platform integrations. Flutter is a valid choice, but rarely the most economical default in DACH.
Databases — Postgres, MySQL, MongoDB, SQLite, ClickHouse, vector DBs
The database choice has long-term consequences — migrations are expensive and risky. Three classes, each with its own field of use.
Relational databases remain the default for 90 percent of all business applications. PostgreSQL is the right choice for nearly every new project in 2026: ACID transactions, JSON support via JSONB, full-text search, geo data via PostGIS, vector search via pgvector. Managed hosting via Neon, Supabase, AWS RDS or Hetzner Cloud Postgres. MySQL remains relevant in existing stacks but has lost feature leadership to Postgres. For new projects we recommend Postgres. SQLite is the right choice for embedded applications, desktop software (with Better-SQLite3 in Electron apps) and small SaaS applications with low write load (Turso, Cloudflare D1).
Document-oriented databases (MongoDB) are significantly less justified in 2026 than five years ago — Postgres with JSONB covers 80 percent of MongoDB use cases with better data consistency. MongoDB only pays off when your data model is truly document-centric and does not map relational relationships.
Specialized databases complement the relational core. ClickHouse for analytics workloads with billions of events and sub-second aggregations, Redis for caching and session storage, Elasticsearch or OpenSearch for full-text search at high volume (for moderate volumes, Postgres's own search is often enough). Vector databases like Qdrant, Weaviate, Pinecone or pgvector become relevant for RAG architectures and semantic search — for most SMB and mid-market use cases pgvector as an extension of the existing Postgres database is enough.
Our default recommendation: PostgreSQL as the single source of truth, Redis for caching when needed, pgvector for semantic search when needed, ClickHouse only once Postgres analytics queries really become too slow. Avoid polyglot persistence (multiple DB systems in parallel) for as long as possible — every additional system costs operations, monitoring and consistency overhead.
Architecture — monolith, modular monolith or microservices
The architecture question is easier to answer for most SMB and mid-market projects in 2026 than the industry portrays. Three tiers, clear decision points.
Monolith: one code base, one deployment, one database. The fastest, simplest and correct approach for 70 percent of all projects. No latency overhead from internal service calls, simple transactions, low operations overhead. Scales with modern hardware well beyond the demands of typical SMB and mid-market applications.
Modular monolith: one code base and one deployment, but with clear module boundaries, clean dependencies and domain-oriented structure. Preparation for a possible later move to separate services without paying the complexity cost today. Our standard architecture for new SMB and mid-market projects — complexity stays manageable while the migration path stays open.
Microservices: multiple separate deployments, each with its own database, communicating via APIs or events. Only pays off once independent deployment cycles per domain become economically valuable — typically at 30 or more developers organized into multiple teams. Advantages: independent scaling, polyglot possible, clear team boundaries. Disadvantages: network latency, distributed transactions, higher operations overhead, harder debugging across service boundaries.
The most common mistake in 2026: microservices are chosen because they sound modern, not because the organization economically needs them. A team of five developers with eight microservices spends 30 to 50 percent of its time on infrastructure topics instead of business features. Our recommendation: start with a modular monolith. If you grow over three years and individual domains genuinely need separate scaling, modules can be carved out into services — the preparation already sits inside the module structure.
The Reepa Solutions approach — we build our own platforms
Reepa Security and Reepa Web Builder — built on modern stacks
We don't just talk about custom software, we build it ourselves and run it in production. Reepa Security (audit platform with over 100 detectors) and the Reepa Web Builder (desktop tool for the lead-to-live pipeline of our customer projects) run on TypeScript, Next.js, Drizzle ORM, PostgreSQL and Electron. Several thousand tests, automated continuous deployment, auto-update via GitHub Releases, signed builds.
The result: software development advice that doesn't come from slides but from running our own products. We know the pitfalls of auto-update chains, native ABI incompatibilities between Electron versions, Drizzle date hydration and cache components in Next.js — because we solved them ourselves.
For customer projects we work with a set process model distilled from over ten years of project experience. Phase 1: discovery in two weeks. We understand the business process, identify the truly differentiating parts, sketch the architecture, clarify the data model and integrations, define the MVP scope with clear abort criteria. Phase 2: build phase in twelve weeks. Incremental delivery in two-week sprints, early user testing from week six, ongoing demo sessions with the business owners. Phase 3: roll-out and handover in four weeks. User training, handover to the internal operations owner, monitoring setup, documentation for audit and further development.
This structure is not academic — it is exactly the approach we use to build our own products and the approach we use to guide customer projects from MVP to productive platform.
Testing strategy — unit, integration, E2E, visual, load
Testing is not a development by-product but a prerequisite for maintainability and changeability. A professional testing strategy follows the pyramid logic: many fast, cheap tests at the base, few slow, expensive tests at the top.
Unit tests check individual functions and modules in isolation, run in milliseconds, and should reach 60 to 80 percent coverage on core business logic. Tools in 2026: Vitest for TypeScript stacks (significantly faster than Jest), Pytest for Python, Go testing for Go. Every pull request checks unit tests automatically in CI.
Integration tests verify the interaction of multiple modules against a real database, real HTTP interfaces or real message queues. Tools: Testcontainers for isolated database instances, MSW for HTTP mocking on the client side. These tests are slower (seconds) but indispensable because they cover the real integration risks that unit tests cannot see.
End-to-end tests verify the full user flow through the application. Tools: Playwright (our default recommendation — fast, stable, good tooling), Cypress (established), Detox for mobile apps. Keep these tests deliberately small — cover the ten most important user paths, not every sub-feature. They are the most expensive tests in setup and maintenance.
Visual regression tests capture UI components as screenshots and alert on unintended visual changes. Tools: Chromatic, Percy, Argos. Useful for design system components and critical UI areas, not for every page.
Load tests verify behavior under load before production launch. Tools: k6 (our recommendation — JavaScript scripts, good scaling), Artillery, Gatling. Define concrete load targets (e.g., 500 concurrent users, 95th percentile under 800 milliseconds) and check them before every major release.
Practical rule of thumb: anyone maintaining a testing pyramid of unit + integration + ten E2E tests can keep an application maintainable with three developers that would otherwise tie up five. Tests are the most important investment in speed beyond the first twelve weeks.
Security by design — OWASP awareness, SCA, DAST in CI
Security is not an optional extra at the end of a project in 2026 — it is a cross-cutting concern through the entire development. Three layers must be covered systematically.
Application security per OWASP Top 10. The OWASP Top 10 has been the established list of the most frequent vulnerability classes for years: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery. Every development team should actively know these classes and address them in code reviews. Standard libraries cover 80 percent — Helmet for HTTP security headers, an ORM with prepared statements against injection, JWT libraries with secure default configurations.
Software Composition Analysis (SCA). Third-party libraries are the most frequent source of vulnerabilities in 2026 — an application typically has 800 to 2,500 transitive dependencies. Tools: Snyk, Dependabot, Renovate, npm audit, OSV-Scanner. Every pull request checks dependencies against current vulnerability databases, with critical findings blocking the merge. With active maintenance, the average patch time for critical vulnerabilities is under seven days.
Dynamic Application Security Testing (DAST) in CI. Automated security scans against the running application in the staging environment. Tools: OWASP ZAP, Reepa Security (our own tool with over 100 detectors), Acunetix. These scans typically run weekly or before every release, finding configuration weaknesses, missing headers, exposed debug endpoints and some classes of injection vulnerabilities. Sensibly complemented by annual manual reviews and audits by external specialists.
Rule of thumb: anyone integrating SCA and DAST into their CI and training their developers once a year in a two-day OWASP Top 10 workshop covers 90 percent of practically relevant application security risks. The remaining 10 percent (business logic weaknesses, industry-specific issues) need an annual external audit.
Performance and Core Web Vitals
Performance is a hard business criterion in 2026, not a nice-to-have. Google rankings, conversion rates and user retention measurably hang on Core Web Vitals. Three metrics are at the center.
Largest Contentful Paint (LCP) measures how quickly the largest visible element loads. Target: under 2.5 seconds at the 75th percentile of all users. Main levers: server response time, image optimization (next/image, AVIF/WebP), critical CSS inlining, CDN use, server-side rendering or pre-rendering.
Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in 2024. Measures reaction time to user interactions. Target: under 200 milliseconds. Main levers: reduce JavaScript bundle size, split main-thread work (requestIdleCallback, web workers), optimize hydration strategy (islands architecture, partial hydration).
Cumulative Layout Shift (CLS) measures visual stability — how much the layout shifts during loading. Target: under 0.1. Main levers: fixed dimensions for images and iframes, skeleton loaders instead of content injected later, caution with webfont loading.
Tools: Lighthouse for local audits, PageSpeed Insights for real field data, Web Vitals JS library for your own monitoring, Vercel Analytics or Sentry Performance for production tracking. We recommend setting Core Web Vitals as a hard build threshold in CI — anyone falling below the threshold cannot deploy to production.
Legacy modernization — Strangler Fig and Anti-Corruption Layer
Many SMB and mid-market companies sit on old software that has been running for ten to twenty years, has become hard to maintain, but carries central business processes. Big-bang replacement (complete rebuild, then cutover) fails very frequently in practice — too big, too long, too risky. Three modern patterns make legacy modernization manageable.
Strangler Fig pattern. You incrementally build new modules around the legacy application and route traffic step by step through a routing layer (reverse proxy, API gateway) to the new components. The legacy application is gradually "strangled" until only the new software remains. Duration for mid-sized legacy systems: 12 to 36 months, with continuous business value over the full runtime and no big-bang moment.
Anti-Corruption Layer (ACL). A translation layer between old and new systems ensures the new software has the clean, modern data model and does not inherit the design weaknesses of the legacy system. The ACL translates between old and new data structures, encapsulates the quirks of the legacy application and can simply be removed once the cut is complete. Without an ACL, every modernization inherits the problems it was supposed to fix.
Branch-by-abstraction. For smaller component swaps (e.g., switching the database, a framework or a third-party library) you introduce an abstraction layer, run old and new implementations in parallel, switch traffic via feature flag in stages, and finally remove the old implementation. This method is the safe choice for internal technical changes without business visibility.
What you should not do: let a rebuild run in stealth mode for two years and then switch over on a weekend. This strategy is responsible for most of the modernization disasters of the last twenty years. Incremental, with clear interim states, is faster and safer in the long run.
Cost and timeline of a custom software project
Realistic numbers from real projects, no marketing optimism. Three size classes.
MVP class (EUR 40,000 to 80,000, 3 to 4 months). A clearly scoped use case, one primary user type, two to four core workflows, one to two external integrations. Team: one senior full-stack, one mid-level full-stack, a part-time product owner, a part-time UX designer. Result: productively usable application for an initial user group, expandable on the basis of real usage data.
Mid-sized business application (EUR 120,000 to 280,000, 5 to 9 months). Customer portal with authentication, internal tool with role concept, vertical platform with moderate complexity. Multiple user roles, five to ten core workflows, four to eight integrations (ERP, CRM, accounting, external APIs), mobile-responsive web interface. Team: two to three developers, an architect, a product owner, a UX designer, a part-time DevOps engineer.
SaaS platform or industry solution (EUR 350,000 to 900,000 in the first year). Multi-tenancy, multiple user roles per tenant, self-service onboarding, billing integration, mobile app or PWA, extensive integration ecosystem, high performance and availability requirements. Team: four to eight developers, an architect, a tech lead, a product owner, a UX designer, a DevOps engineer, a QA engineer.
Ongoing operating costs: 15 to 25 percent of the initial investment per year. Hosting, monitoring, security updates, library upgrades, smaller feature adjustments. Anyone who does not plan for this maintenance ends up with outdated, hard-to-maintain software within three years — the most common reason for premature rebuilds that were actually avoidable.
Vendor selection checklist — nearshore, offshore vs in-house
Three sourcing options, each with a clear cost-risk profile.
In-house development makes sense when software is your core product and you want to retain the knowledge long term. Cost per senior developer in DACH: EUR 90,000 to 130,000 annual salary plus 25 to 30 percent overhead, realistically EUR 115,000 to 170,000 fully loaded. Plus recruiting (12 to 24 weeks time-to-hire), onboarding (3 to 6 months to full productivity), and personnel risks (illness, resignation, parental leave).
Nearshore (Portugal, Poland, Romania, Spain, Bulgaria) is the most frequent choice in the mid-market in 2026. Hourly rates EUR 50 to 65 for senior developers, same time zone, similar work culture, English as common working language, EU data-protection level. Advantages over in-house: faster availability, flexible team size, no personnel risk. Disadvantages: less knowledge retention inside the company, higher communication effort than in-house.
Offshore (India, Vietnam, Latin America, Egypt) starts at hourly rates of EUR 25 to 45. Requires significantly tighter specification, more review effort, good technical leadership on your side. Time-zone difference can be an advantage or disadvantage depending on region (Latin America good for DACH hours, Asia interesting for 24/7 setups). Risk factor: quality spread is wide, very productive with a good vendor, quickly more expensive than nearshore with a mediocre one.
Hybrid model is the frequent choice in the mid-market in 2026: architecture, lead development and product owner role in-house or nearshore, delivery teams in a cheaper offshore setup. This combination delivers knowledge retention at the core and cost efficiency at the breadth.
Selection checklist for external vendors: references from comparable industries and sizes, a code sample from a running project (with the client's permission), clear role definition (who is tech lead, architect, senior, junior), documented test and review practice, contractual IP transfer to you, GDPR-compliant data protection with a data processing agreement, clear escalation and termination clauses, monthly fixed-price component plus an hourly component for transparency.
Your software project — from idea to production system
In a free 30-minute conversation we clarify scope, tech stack, architecture and a realistic budget. No generic answers, but a concrete assessment of your project.
Book a consultationFrequently asked questions
What does custom software cost in 2026?
A focused custom software product with a clearly scoped MVP starts at EUR 40,000 to 80,000 for three to four months of build time. Mid-sized business applications (customer portal, internal tool, vertical platform) fall in the EUR 120,000 to 280,000 range. Larger SaaS platforms or industry solutions with multi-tenancy, integrations and a mobile client typically range between EUR 350,000 and 900,000 in the first year. Plan for ongoing operating costs (hosting, monitoring, maintenance) at 15 to 25 percent of the initial investment per year.
Custom software or off-the-shelf — when is which worth it?
Off-the-shelf is worth it when your process can adapt to established software — accounting, classic CRM, office workflows. Custom software is worth it when the process is your differentiator or when no suitable off-the-shelf solution exists. Rule of thumb: if customizing an off-the-shelf solution costs more than 40 percent of the license price, custom software is usually the more economical and structurally more stable choice over the long term.
Which tech stack is the safe choice for web apps in 2026?
For most SMB and mid-market projects: TypeScript as the language, Next.js (App Router) or SvelteKit as the framework, Tailwind CSS for UI, PostgreSQL as the database, Drizzle or Prisma as the ORM, Vercel or a classic PaaS for hosting. This stack is stable, has broad developer availability, good performance and long-term maintainability. Vue with Nuxt 4 or Svelte 5 are also solid alternatives, depending on team experience.
Do we need microservices or is a monolith enough?
For 90 percent of SMB and mid-market projects, a modular monolith is enough — a well-structured single application with clear module boundaries. Microservices only pay off above a certain team size (typically 30+ developers), when independent deployment cycles per domain become economically valuable. Starting with five developers and three teams on microservices builds in complexity you don't need — and you pay for it in latency, operations overhead and bugs.
REST, GraphQL or gRPC — which API style is right?
REST is the default for public APIs and partner integrations — widely understood, well tooled. GraphQL is worth it with multiple clients that have different data needs (web + mobile + public API) and when over- or under-fetching is a real problem. gRPC is the right choice for internal service-to-service communication with high throughput and tight latency requirements. tRPC is a pragmatic option for TypeScript monorepos where client and server are maintained by the same team.
Native iOS/Android or React Native/Flutter for our app?
Native (Swift, Kotlin) is the choice when you need a premium experience using the latest platform APIs, frequent hardware access (camera, Bluetooth, AR), or when building a UX-demanding consumer app. React Native and Flutter reach 80 to 90 percent of native experience at 40 to 60 percent of the effort and are the right choice for business apps, B2B tools and standard use cases. Capacitor or PWA are enough for information and administration apps without high hardware requirements.
How long does MVP development take?
A truly tight MVP scope can be built in 8 to 12 weeks — from discovery to the first production user group. We recommend a 90-day model to our customers: 30 days discovery and design, 45 days build time, 15 days stabilization and roll-out. Anyone planning 6 months for an MVP usually packs in too many features — the point of an MVP is not completeness, but the fastest robust validation of the core hypothesis.
Nearshore, offshore or in-house — how do we choose?
In-house makes sense when software is your core product and you want to retain the knowledge long term — cost point EUR 90,000 to 130,000 per senior developer per year in DACH. Nearshore (Portugal, Poland, Romania, Spain) offers EUR 50 to 65 per hour at the same time zone and similar work culture. Offshore (India, Vietnam, Latin America) starts at EUR 25 to 45 per hour but requires tighter specification, more review effort and good lead architecture on your side. For many mid-market companies, a hybrid makes sense: architecture and lead developers in-house or nearshore, delivery teams offshore.
How do we ensure software quality without a bloated QA team?
With a pyramid strategy: many fast unit tests per module (target 60 to 80 percent coverage on core logic), integration tests against a real database and external interfaces (Vitest, Pytest, Testcontainers), E2E tests for the most important user paths (Playwright, Cypress, Detox for mobile), visual regression tests for UI-critical components (Chromatic, Percy). This pyramid automates 95 percent of QA without a large manual test team. Manual testing remains reserved for exploratory testing and acceptance reviews.
How do we modernize old software without big-bang risk?
With the Strangler Fig pattern: you incrementally build new modules around the legacy application, gradually route traffic through a routing layer to the new components, and only shut down the old parts once the new ones are running in production. An anti-corruption layer translates between old and new data models so the new software doesn't inherit the design weaknesses of the old one. This method takes 12 to 36 months for mid-sized legacy systems, but carries no big-bang risk and delivers continuous business value across the full runtime.
Deep-dive articles & cases
This pillar covers the overview — for operational depth we point to the specialized articles per topic area. Each article stands on its own and links back to this software guide. Note: the linked deep-dive articles are currently available in German only.
Custom software vs off-the-shelf
Decision framework with cost, risk and differentiation assessment.
Web app stack 2026
TypeScript, Next.js, SvelteKit, Tailwind and the right stack choice per project type.
Building a SaaS — a guide
Multi-tenancy, billing, self-service onboarding and scaling architecture.
Native vs hybrid mobile app
Swift/Kotlin, React Native, Flutter and Capacitor in a practical comparison.
REST vs GraphQL vs gRPC
API styles, tools and a decision matrix for internal and external interfaces.
Building an MVP in 90 days
Scope, phase plan and abort criteria for the fast first cut.
Monolith vs microservices
Modular monolith as the default and when microservices really pay off.
Agile vs waterfall
Which process model fits which project type in the mid-market?
Nearshore vs offshore vs in-house
Cost, risk and steering effort of the three sourcing models.
TypeScript stack 2026
Tools, libraries and configurations for productive TypeScript projects.
Low-code vs custom code
Power Platform, Mendix, Retool and OutSystems compared with in-house builds.
What does software development cost in 2026
Realistic price ranges for MVP, business application and SaaS platform.
Legacy modernization
Strangler Fig, Anti-Corruption Layer and branch-by-abstraction in practice.
Testing strategy for the mid-market
Test pyramid, tools and sensible coverage targets per test class.
PWA vs native
When a Progressive Web App is enough and when a native app is needed.
From our projects
AI Chatbot — Knowledge Assistant for the Mid-Market
RAG-based chatbot with source citations, EU data residency and GDPR-compliant architecture, integrated into the existing customer portal.
E-Commerce Platform — Custom Stack Instead of Standard Shop
High-performance B2B commerce platform with custom pricing logic, ERP integration and multilingual frontend on Next.js and PostgreSQL.
Customer Portal — Self-Service for 2,500 Business Customers
Custom customer portal with role concept, document vault, contract overview and API integration to ERP and CRM.
Ready for the first step?
Book a free 30-minute conversation to position your software project. Afterwards you will know whether you need a discovery workshop, an MVP project or an architecture consultation first — or whether an off-the-shelf solution is the better path after all.
Book a consultation
IT security and cloud architect with over ten years of experience. Builds the Reepa platforms (Reepa Security, Reepa Web Builder) with his team on modern TypeScript stacks and runs them in production. Writes regularly on software architecture, stack choice and build-vs-buy decisions for SMB and mid-market companies.
Reviewed on: 22 May 2026 · More about Hakan