In 2026, software is no longer just a tool for mid-sized companies — it is the central lever for differentiation, scaling and operational efficiency. Anyone who captures a business process in software can measure it precisely, improve it step by step and scale it without additional staff. Anyone who runs it as an Excel spreadsheet, email ping-pong or verbal handover pays friction costs 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 right, which tech stack will carry you reliably in 2026, what a professional architecture looks like and which costs are realistic.
Why custom software development is a competitive advantage in 2026
Over the past ten years, mid-sized companies in the DACH region have mostly relied on standard software — and that was usually the right decision. Accounting, classic CRM and core ERP functions are standardized because they work similarly everywhere. But that is exactly what creates a problem: if all your competitors work with the same standard software, software can no longer be a differentiator. Today, competitive advantages arise where you have processes that your competition doesn't have — and mapping these processes rarely works with standard software.
Three drivers make custom software economically more attractive in 2026 than it was 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 to 2020. Second, AI assistance: developer tools like Cursor, GitHub Copilot and Claude Code now write the boilerplate code that used to swallow 30 percent of build time. Third, rising standard-software costs: SaaS licenses have increased by 25 to 60 percent over the past three years, while features were shifted into higher tiers in parallel. Above a certain annual license sum, building it yourself becomes more economical than ever-higher rental fees.
In practice this means: anyone with a business process that is truly their own should do an honest calculation in 2026 of whether the continuous adaptation of a standard solution still pays off economically — or whether a focused in-house development with a clear MVP scope isn't the better investment for the next ten years.
Custom software vs off-the-shelf vs low-code — a decision framework
Three options are available today, and each has a clear usage profile. The decision is not a matter of belief but depends on a few objective criteria.
Standard 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 perfect fit, and the annual license volume stays below roughly 30,000 euros. 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 it's about internal tools with manageable complexity, the team has a technically savvy power user (citizen developer), and maintainability over five to seven years is acceptable. Caution point: low-code feels faster at first, but quickly becomes unmaintainable as logic grows and creates vendor lock-in. Often the right choice for form-heavy internal workflows, rarely for customer products.
Custom software is right when the process is your differentiator, no suitable standard solution exists, there are several hundred users or high demands on UX, performance or compliance, or the annual license sum of a standard solution exceeds 50,000 euros and keeps growing. Classic fields: industry-specific 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 choose a standard solution, adapt it with customizing, pay 60 to 120 percent of the license price in adaptation costs over the years and end up sitting on a poorly maintainable special solution wrapped in a standard shell. If you already notice during discovery that more than 30 percent of the license functions remain unused and more than 30 percent need to be added through customizing, custom software is usually the more economical choice.
Web applications 2026 — TypeScript, Next.js, Vue, SvelteKit, Tailwind
In 2026, web applications are the dominant form of business software — ahead of mobile apps, ahead of desktop applications. Three reasons: universal reach without installation, central updates without device rollout, a unified tech stack between internal administration and external customer portal. The stack question has consolidated over the past few years.
TypeScript as the language is the undisputed right choice for new development 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 medium-sized applications with a small to medium team.
Vue.js with Nuxt 4 remains a valid choice, particularly strong in Europe. Lower barrier to entry than React, good performance, an established ecosystem. Sensible if your team already has Vue experience or if you are looking for 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 mid-sized 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 determines how well your application works together 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, an excellent toolchain (OpenAPI/Swagger for specification and code generation, Postman/Insomnia for tests, caching via standard HTTP mechanisms). Disadvantages: over-fetching and under-fetching with complex UIs, many endpoints with large data models. The right first choice for 70 percent of all projects.
GraphQL is worth it 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), a steeper learning curve for the team.
gRPC is the right choice for internal service-to-service communication with high throughput and tight latency requirements — Protobuf schema, HTTP/2, streaming natively supported. Sensible in microservice architectures or for real-time data streams. Unsuitable for external APIs, because browser support only works via 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 the database to the UI without a separate API specification, without code generation. Very productive for internal tools and small to medium 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 requirements, GraphQL only when there is a 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 mid-sized requirements can be covered with a Progressive Web App (PWA). But if you really need an app, four options are available.
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-near functions (Bluetooth Low Energy, NFC, camera control). Effort: two separate codebases, the highest implementation and maintenance effort, but the best UX and the best platform integration.
React Native is the established cross-platform choice for business and B2B apps in 2026. A TypeScript stack, a very broad library selection, native modules loadable on demand. With Expo as the framework, the initial complexity drops significantly. Reaches 85 to 95 percent of the native experience at 50 to 60 percent of the effort compared to two native codebases.
Flutter is Google's cross-platform answer, with its own language (Dart) and its own rendering. It delivers pixel-perfect UIs on iOS and Android and, if desired, web and desktop too. Advantage: consistent look across platforms, very good performance for animations. Disadvantage: Dart is a niche language, a smaller talent pool than React Native, fewer third-party libraries.
Capacitor (Ionic) wraps a web application in a native container. Suitable when you have a web application and want to bring it into the app stores without major rework. UX quality is well below Native and React Native, but the effort is minimal. Sensible for internal tools, information apps or as a bridge to a later real mobile build.
Our recommendation: PWA as the default, React Native with Expo for genuine mobile needs, Native only for premium consumer apps or strong platform integrations. Flutter is a valid choice, but rarely the most economical default in the DACH region.
Databases — Postgres, MySQL, MongoDB, SQLite, ClickHouse, vector DBs
The database choice has long-term consequences — switches are costly 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 almost 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 its feature lead against 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 far less justified in 2026 than they were five years ago — Postgres with JSONB covers 80 percent of MongoDB use cases, with better data consistency. MongoDB is only worth it when your data model is genuinely document-centric and maps no 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 mid-sized 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 if needed, pgvector for semantic search if 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 effort.
Architecture — Monolith, Modular Monolith or Microservices
For most mid-sized projects, the architecture question is easier to answer in 2026 than the industry makes it out to be. Three stages, clear decision points.
Monolith: one codebase, one deployment, one database. The fastest, simplest and, for 70 percent of all projects, the right approach. No latency overhead from internal service calls, simple transactions, low operational effort. Scales with modern hardware far beyond the requirements of typical mid-sized applications.
Modular Monolith: one codebase and one deployment, but with clear module boundaries, clean dependencies and a domain-oriented structure. Preparation for the possible later step toward separate services, without paying the complexity costs today. Our standard architecture for new mid-sized projects — complexity stays manageable, the migration path stays open.
Microservices: several separate deployments, each with its own database, communicating via APIs or events. Only worth it once independent deployment cycles per domain become economically valuable — typically from 30 or more developers, organized into multiple teams. Advantages: independent scaling, language diversity possible, clear team boundaries. Disadvantages: network latency, distributed transactions, higher operational effort, 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 functions. Our recommendation: start with a Modular Monolith. If you grow in three years and individual domains really need to scale separately, modules can be split out into services — the preparation is already built into the module structure.
Reepa Solutions approach — we build our platforms ourselves
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 (an audit platform with over 100 detectors) and the Reepa Web Builder (a 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, automatic continuous deployment, auto-update via GitHub Releases, signed builds.
The result: software development consulting that doesn't come from slides, but from our own operations. We know the pitfalls of auto-update chains, of native ABI incompatibilities between Electron versions, of Drizzle date hydration and of Cache Components in Next.js — because we solved them ourselves.
For customer projects we work with a fixed process model that we 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, and define the MVP scope with clear stop criteria. Phase 2: Build phase in twelve weeks. Incremental delivery in two-week sprints, early user tests from week six, continuous demo sessions with the business department. Phase 3: Rollout and handover in four weeks. User training, handover to the internal operations owner, monitoring setup, documentation for audit and further development.
This structure isn't academic — it is exactly the approach we use to build our own products and to accompany customer projects from MVP to productive platform.
Testing strategy — Unit, Integration, E2E, Visual, Load
Testing is not a by-product of development but the 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 in the 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 the unit tests automatically in CI.
Integration tests check the interplay 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 don't see.
End-to-end tests check the complete user flow through the application. Tools: Playwright (our default recommendation — fast, stable, good tooling), Cypress (established), Detox for mobile apps. Deliberately keep these tests small — cover the ten most important user paths, not every sub-function. They are the most expensive tests in setup and maintenance effort.
Visual regression tests capture UI components as screenshots and alert you to unintended visual changes. Tools: Chromatic, Percy, Argos. Sensible for design-system components and critical UI areas, not for every page.
Load tests check behavior under load before going into production. 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 these before every major release.
Practical rule of thumb: anyone who maintains a testing pyramid of Unit + Integration + ten E2E tests can keep an application maintainable with three developers that would tie up five developers without tests. Tests are the most important investment in speed beyond the first twelve weeks.
Security by design — OWASP awareness, SCA, DAST in CI
In 2026, security is not an optional add-on at the end of the project but a cross-cutting topic throughout the entire development. Three levels must be covered in a structured way.
Application security according to OWASP Top 10. The OWASP Top 10 have for years been the established list of the most common vulnerability classes: 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 a default-secure configuration.
Software Composition Analysis (SCA). Third-party libraries are the most common 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 the dependencies against current vulnerability databases, critical findings block 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. Usefully complemented by annual manual reviews and audits by external specialists.
Rule of thumb: anyone who integrates SCA and DAST into their CI and trains their developers once a year in a two-day OWASP Top 10 workshop covers 90 percent of the practically relevant application security risks. The remaining 10 percent (business-logic weaknesses, industry specifics) require an annual external audit.
Performance and Core Web Vitals
In 2026, performance is a hard business criterion, not a feel-good topic. Google ranking, conversion rates and user retention depend measurably on Core Web Vitals. Three metrics are at the center.
Largest Contentful Paint (LCP) measures how quickly the largest visible element is loaded. 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 usage, server-side rendering or pre-rendering.
Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in 2024. It measures the response time to user interactions. Target: under 200 milliseconds. Main levers: reduce JavaScript bundle size, split main-thread work (requestIdleCallback, Web Workers), optimize the 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 subsequently inserted content, caution with web-font loading.
Tools: Lighthouse for local audits, PageSpeed Insights for real field data, the 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 — whoever falls below the threshold cannot deploy to production.
Legacy modernization — Strangler Fig and Anti-Corruption Layer
Many mid-sized 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 redevelopment, then cut-over) fails very often in practice — too big, too long, too risky. Three modern patterns make legacy modernization manageable.
Strangler Fig pattern. You build new modules around the legacy application step by step and gradually route traffic through a routing layer (reverse proxy, API gateway) to the new components. The legacy application is "wrapped" piece by piece until in the end only the new software remains. Duration for medium legacy systems: 12 to 36 months, but with continuous business value over the entire runtime and not a single big-bang moment.
Anti-Corruption Layer (ACL). A translation layer between old and new systems ensures that the new software has the clean, modern data model and doesn't inherit the design flaws 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 replacement is complete. Without an ACL, every modernization inherits the very problems it was meant 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 the old and new implementation in parallel, switch traffic over via feature flag in stages, and finally remove the old implementation. This method is the safe choice for internal technical rework without business visibility.
What you should not do: run a redevelopment in stealth mode for two years and then switch over on a weekend. This strategy is responsible for most modernization disasters of the past twenty years. Incremental, with clear interim states, is faster and safer in the long run.
Costs and timeline of custom software
Realistic figures from real projects, no marketing optimism. Three size classes.
MVP class (40,000 to 80,000 euros, 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 product owner part-time, a UX designer part-time. Result: a productively usable application for a first user group, expandable based on real usage data.
Mid-sized business application (120,000 to 280,000 euros, 5 to 9 months). A customer portal with authentication, an internal tool with a role concept, a domain-specific platform of moderate complexity. Multiple user roles, five to ten core workflows, four to eight integrations (ERP, CRM, accounting, external APIs), a mobile-responsive web interface. Team: two to three developers, an architect, a product owner, a UX designer, a part-time DevOps.
SaaS platform or industry solution (350,000 to 900,000 euros in the first year). Multi-tenancy, multiple user roles per tenant, self-service onboarding, billing integration, a mobile app or PWA, an 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 doesn't budget for this maintenance will have outdated, hard-to-maintain software in three years — the most common reason for premature redevelopments 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 the DACH region: 90,000 to 130,000 euros annual salary plus 25 to 30 percent overhead, so realistically 115,000 to 170,000 euros on a fully loaded basis. Plus recruiting (12 to 24 weeks time-to-hire), onboarding (3 to 6 months to full productivity), staffing risks (illness, resignation, parental leave).
Nearshore (Portugal, Poland, Romania, Spain, Bulgaria) is the most common choice in the mid-market in 2026. Hourly rates 50 to 65 euros for senior developers, the same time zone, a similar work culture, English as the shared working language, EU data-protection level. Advantages over in-house: faster availability, flexible team size, no staffing risk. Disadvantages: lower knowledge retention within the company, higher communication effort than with in-house.
Offshore (India, Vietnam, Latin America, Egypt) starts at hourly rates of 25 to 45 euros. It requires significantly tighter specification, more review effort, good technical leadership on your side. The time-zone difference can be an advantage or disadvantage depending on the region (Latin America fits DACH hours well, Asia is interesting for 24/7 setups). Risk factor: quality variance is large; with a good vendor very productive, with a mediocre vendor quickly more expensive than nearshore.
Hybrid model is a common choice in the mid-market in 2026: architecture, lead development and the product-owner function in-house or nearshore, delivery teams in the cheaper offshore setup. This combination delivers knowledge retention at the core and cost efficiency across the breadth.
Selection checklist for external vendors: references from comparable industries and sizes, a code sample from an ongoing 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, data-protection conformity with a GDPR data-processing agreement, clear escalation and termination rules, a monthly fixed-price component plus an hours-based portion for clarity.
Your software project — from idea to productive 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 project with a clearly scoped MVP starts at 40,000 to 80,000 euros for three to four months of build time. Mid-sized business applications (customer portal, internal tool, domain-specific platform) range from 120,000 to 280,000 euros. Larger SaaS platforms or industry solutions with multi-tenancy, integrations and a mobile client typically run between 350,000 and 900,000 euros in the first year. Budget 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 no suitable off-the-shelf solution exists on the market. Rule of thumb: if you pay more than 40 percent of the license price in customizing to adapt an off-the-shelf solution, custom software is usually the more economical and long-term more stable choice.
Which tech stack is the safe choice for web apps in 2026?
For most mid-sized 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 all mid-sized projects, a Modular Monolith is enough — a well-structured single application with clear module boundaries. Microservices only become worthwhile beyond a certain team size (typically 30+ developers), when independent deployment cycles per domain become economically valuable. Anyone who starts with five developers and three teams on microservices builds in complexity they don't need — and pays for it in latency, operational overhead and bugs.
REST, GraphQL or gRPC — which API variant 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 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 current platform APIs, have frequent hardware access (camera, Bluetooth, AR) or are building a very UX-demanding consumer app. React Native and Flutter reach 80 to 90 percent of the 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 a PWA are enough for information and administrative apps without high hardware requirements.
How long does MVP development take?
A genuinely tight MVP scope can be built in 8 to 12 weeks — from discovery to the first productive user group. We recommend our clients a 90-day model: 30 days of discovery and design, 45 days of build time, 15 days of stabilization and rollout. Anyone who budgets 6 months for an MVP usually crams 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 90,000 to 130,000 euros per senior developer and year in the DACH region. Nearshore (Portugal, Poland, Romania, Spain) offers 50 to 65 euros per hour in the same time zone and with a similar work culture. Offshore (India, Vietnam, Latin America) starts at 25 to 45 euros per hour, but requires tighter specification, more review effort and good lead architecture on your side. For many mid-sized 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 in the 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 checks.
How do we modernize old software without big-bang risk?
With the Strangler Fig pattern: you build new modules around the legacy application step by step, gradually route traffic through a routing layer to the new components, and only switch off the old parts once the new ones run in production. An Anti-Corruption Layer translates between old and new data models so the new software doesn't inherit the design flaws of the old. This method takes 12 to 36 months for medium legacy systems, but has no big-bang risk and delivers continuous business value over the entire runtime.
In-depth articles & cases
This pillar covers the overview — for operational depth we point you to the specialized articles per topic area. Each article is usable on its own and links back to this software guide.
Custom software vs off-the-shelf software
A 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.
Build a SaaS — 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.
Develop an MVP in 90 days
Scope, phase plan and stop criteria for a fast first draft.
Monolith vs microservices
The Modular Monolith as the standard and when microservices really pay off.
Agile vs waterfall
Which process model fits which project type in mid-sized companies?
Nearshore vs offshore vs in-house
Costs, risks and management 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 to in-house development.
What does software development cost in 2026
Realistic price ranges for an MVP, business application and SaaS platform.
Legacy modernization
Strangler Fig, Anti-Corruption Layer and Branch by Abstraction in practice.
Testing strategy for mid-sized companies
The 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 necessary.
From our projects
AI chatbot — knowledge assistant for mid-sized companies
A RAG-based chatbot with source citations, EU data residency and a GDPR-compliant architecture, integrated into the existing customer portal.
E-commerce platform — custom stack instead of a standard shop
A high-performance B2B trading platform with custom pricing logic, ERP connection and a multilingual frontend on Next.js and PostgreSQL.
Customer portal — self-service for 2,500 business customers
A custom customer portal with a 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 take stock of your software project. Afterwards you'll know whether you need a discovery workshop, an MVP project or first an architecture consultation — or whether an off-the-shelf solution is the better path after all.
Book a consultation
An IT security and cloud architect with over ten years of experience. With his team, he develops the Reepa platforms (Reepa Security, Reepa Web Builder) on modern TypeScript stacks and runs them in production. He writes regularly about software architecture, stack selection and build-vs-buy decisions for mid-sized companies.
Reviewed on: May 22, 2026 · More about Mina