Custom Web Software Solutions

Those ranges describe the US agency market, not a price list. A Master Web quote is built bottom-up from your scope rather than from a rate card, so the figure reflects the modules, integrations and compliance work you actually need. The honest answer is always a scoped quote, and you receive it within one business day of the discovery call.

Three things move the number more than anything else: the count of distinct modules, the number of external systems to integrate, and compliance requirements. Unclear scope is the hidden cost: industry data shows estimates overrun by 20–35% when requirements are vague, which is why discovery comes first.

• Market range, basic internal tool: about $50,000–90,000 (US rates)
• Market range, customer-facing platform: about $120,000–200,000 (US rates)
• Compliance add-ons (market): GDPR +10–15%, SOC 2 +15–25%, HIPAA +25–40%
• Maintenance after launch: 15–25% of the build cost per year (market range)

Integrations deserve special attention. Each ERP, CRM, payment or shipping connection needs its own analysis, field mapping, error handling and testing, and older systems without a documented API cost more than modern ones. Reporting is another frequent surprise: a report that sounds simple can require new data structures underneath.

Project duration and team size follow from those five factors. Master Web prices the Starter, Professional and Enterprise scopes after the needs analysis, so you see which factors drive your figure before you commit. Moving a module to phase two is the quickest way to lower the first invoice without compromising the architecture.

• Modules and screens: each distinct workflow adds analysis, design, build and test time
• Users and roles: role-based access and high concurrency raise backend complexity
• Integrations: ERP, CRM, accounting, payments, shipping, marketplaces
• Compliance: GDPR, SOC 2 or HIPAA add audit and documentation work
• Design: themed admin interface versus fully bespoke customer-facing screens

Fixed price shifts the estimation risk to the agency, so it includes a contingency and a formal change-request process; every new idea becomes a priced change. That is the right trade for a dealer portal or an internal tool with a known process and a fixed budget approval.

Time and materials fits SaaS products and anything with uncertain requirements. You pay for the work done each sprint, see a demo, and can stop or redirect at the end of any sprint. A common hybrid is a fixed-price discovery and MVP, then sprints for growth.

• Fixed price: known scope, formal change requests, contingency built in
• Sprints: evolving scope, budget per sprint, stop or redirect at any sprint end
• Hybrid: fixed-price discovery and MVP, then sprint-based growth

Run the comparison honestly. SaaS cost is the subscription times seats times years, plus the hidden cost of the processes the tool cannot handle, such as spreadsheets and double entry. Custom cost is the build plus 15–25% of that figure per year for maintenance and improvements (market range), plus hosting.

Custom software also brings assets a subscription never does: you own the code, the data model fits your process, and integrations are built once instead of rented. The risk is scope. Keep phase one small and the break-even arrives sooner.

• SaaS wins: small teams, standard processes, no integration needs
• Custom wins: 50–200+ users, unique workflows, heavy integrations, data ownership
• Compare both on a three-to-five-year horizon, including maintenance

License costs depend on the stack. The Master Web stack (React, Next.js, TypeScript, Node.js, PostgreSQL or MySQL) is open source with no per-seat license, so the recurring costs are hosting, the third-party services you choose (payment gateway, email, maps, AI APIs) and the maintenance agreement.

Cloud hosting is a separate, usage-based cost, usually paid directly to the provider so the account stays in your name. A single-module internal tool runs on a small cloud instance; a SaaS platform with thousands of tenants needs load balancing, managed databases and backups across regions, and the bill grows with traffic. Ask for a hosting estimate alongside the build quote so there are no surprises in month two.

• Maintenance agreement: security patches, monitoring, backups, new features
• Hosting: cloud instances, managed database, storage, CDN, scaled to usage
• Third-party services: payment gateway, email, SMS, maps, AI APIs (pay as you go)
• Open-source stack: no per-seat or runtime license fees

Pick the module that removes the most manual work or unlocks revenue soonest: an order portal for dealers, a quoting tool for sales, a booking flow for customers. Launch it, measure usage for a few weeks, then prioritize the next module from real behavior rather than from the original wish list.

An MVP is not a prototype to be thrown away. The data model, authentication, roles and API are built to production standard in phase one, which is what makes later phases cheaper than starting over.

• Phase one: the single highest-value workflow, built to production quality
• Measure for a few weeks, then prioritize phase two from real usage
• Starter scope: single module, admin panel, basic API, source code, 3 months maintenance

What stretches a timeline is rarely coding. Waiting for integration credentials, late test feedback and decisions that stay open for weeks add more days than any technical problem. Master Web tracks delivery sprint by sprint, so slippage shows up at the next demo rather than at the deadline, and the milestone schedule marks the dependencies on your side.

Launch is not the end date. Plan a short stabilization window after go-live for data checks, user training and the first round of fixes; bug fixes in this window fall within the included maintenance period.

• Single module: 4–8 weeks
• Corporate multi-module system: 2–4 months
• SaaS or multi-tenant platform: 4–8 months
• Discovery before any of these: 1–3 weeks (market norm)

Discovery produces a scope document and a milestone schedule. Design covers UX/UI and the technical architecture: data model, roles, integrations and hosting. Development then works through the backlog in priority order, and launch includes deployment, any data migration in the scope, training and the handover of code and documentation.

Your side of the process matters as much as ours. The projects that finish on time have one decision-maker who can approve a screen within days, a person who tests each demo and reports back before the next sprint, and early access to the data, documents and system credentials the integrations need.

• Stage 1: discovery workshop, scope document, written quote
• Stage 2: UX/UI design, data model, architecture, hosting plan
• Stage 3: sprints with demos, continuous testing, your feedback each sprint
• Stage 4: deployment, scoped migration, training, documentation, maintenance period
• From you: a decision-maker, a tester, data and system access on time

Discovery answers the expensive questions before code exists: which workflows go into phase one, who the user roles are, which systems must connect and what data has to migrate. Every hour spent here saves several later, because changing a data model on paper is cheap and changing it in production is not.

A good scope document is also a procurement asset. If you decide to pause or to collect other quotes, it gives every vendor the same baseline, which makes offers comparable instead of apples to oranges.

• Free: first discovery call, needs analysis, written quote within one business day
• Deeper analysis: workshops, process mapping, scope document, architecture
• Outputs: prioritized backlog, data model, integration list, milestone schedule

The scope document fixes what is in and out of phase one, every new idea is estimated before it enters the backlog, and sprint demos keep changes small and early rather than large and late. New ideas are not the enemy; unpriced ideas are.

When a stakeholder asks for a feature mid-project, it is written up, estimated and then either swapped for something of equal size in the current phase, moved to the next phase, or approved as a paid change. Nothing silently expands the sprint.

On a sprint-based contract you also hold the second lever: priority. Because you reorder the backlog before each sprint, the budget always goes to the most valuable remaining work, and the launch date is protected by cutting the least valuable items, not by overtime.

• Scope document: in-scope, out-of-scope and assumptions written down
• Change requests: estimated and approved in writing before work starts
• Regular sprint demos keep every change small and reversible

Desktop software, by contrast, installs per machine and has to be updated and backed up on each one. Typical web software includes dealer portals, CRMs, booking and quoting systems, production tracking, HR tools and SaaS products. Because the logic lives on the server, updates ship once for all users, access can be controlled by role, and the same backend can serve a mobile app through an API.

The line between website and web application is where the brief changes. If your project is mostly pages, a blog and a contact form, the web design service is the right fit; if it needs accounts, roles, data entry and integrations, you need web software, even if it also has a public front.

• Website: pages, content, forms, SEO; visitors read and get in touch
• Web application: login, roles, workflows, data, integrations, reports
• Desktop software: installed per device, updated and backed up locally

Why these specifically: TypeScript catches a whole class of bugs before the code runs, Next.js gives fast server-rendered pages where SEO matters and app-like interactivity where it does not, and PostgreSQL handles relational business data with strong integrity. Docker makes the same build run identically on a laptop, a staging server and production.

Architecture follows the project, not fashion: a single-module tool is one well-structured application, a SaaS platform may split into services behind an API gateway. SPA, PWA and server-side rendering are all options, chosen per screen type.

• Frontend: React, Next.js, TypeScript; SPA, PWA or SSR as needed
• Backend: Node.js, REST APIs, microservices for large platforms
• Data: PostgreSQL or MySQL, with versioned migrations and backups
• Infrastructure: Docker containers, cloud hosting, CI/CD pipelines

Because the build ships as Docker containers, the same software runs in either environment. The cost comparison goes beyond the monthly bill. Own servers need hardware refresh, a person on call, patching, backup testing and physical security; cloud turns those into a usage fee and a shared responsibility. For a small internal tool the cloud bill is modest; for a data-heavy platform, reserved capacity or a hybrid setup can be cheaper.

Whichever you choose, open the cloud or hosting account in your company name and grant the development team operator access, so ownership of the infrastructure never depends on the vendor relationship.

• Cloud: elastic scaling, managed database, automated backups, region choice
• On-premises: required by some regulators or client contracts; you run the operations
• Hybrid: sensitive data on-site, public-facing services in the cloud
• Always: cloud and server accounts registered in your company name

Integration work has four parts: field mapping between systems, the direction and frequency of sync (real time, hourly, nightly), error handling with retries so a failed order does not vanish, and sandbox testing before production. Older ERPs without a modern API can still be connected through database views, file exchange or middleware, at higher effort.

Three patterns come up constantly. A B2B portal reads prices and stock from the ERP and writes orders back. A CRM sync pushes web leads into the pipeline, and an accounting integration creates invoices automatically when an order is confirmed.

• Needed from you: API credentials, documentation, a sandbox or test tenant
• Decide early: sync direction, frequency, conflict rules, error alerts
• Legacy systems: possible via database views, files or middleware, with more effort

Typical modules: customer-specific pricing and discount groups, live or nightly stock sync, order and backorder tracking, invoices and statements, campaign announcements, sales-rep views for field teams and a returns workflow. Dealer management systems and B2B portals are one of the corporate web software areas Master Web builds, usually within the Professional scope with ERP integration.

The business case is usually simple: count the hours your team spends keying orders and answering stock and balance questions, then compare that with the portal budget. Dealers who can browse the full catalog themselves also discover products a phone order never mentioned.

• Dealer-specific prices, discount groups and credit limits
• Stock, order status, backorders, invoices and account statements
• Orders written straight into the ERP; no re-keying
• Sales-rep and field-team views, campaign announcements, returns

Technically a SaaS product needs multi-tenant architecture, subscription billing, role management, usage metering and an onboarding flow. Multi-tenancy is the decision that is hardest to change later. One shared database with tenant isolation is cheaper to run; separate databases per tenant are easier to sell to enterprise buyers who ask about data separation.

Billing comes next: plans, trials, upgrades, failed payments and invoices through a payment gateway such as Stripe. The Enterprise scope adds what a growing SaaS needs: microservice infrastructure where justified, high-traffic scaling, DevOps with CI/CD pipelines, SLA-backed support and a dedicated development team that stays with the product after launch.

• Discovery: first use case, tenant model, pricing plans, success metrics
• MVP: core workflow, signup and onboarding, billing, admin panel
• Platform: multi-tenant isolation, usage metering, API, scaling, monitoring
• Team: dedicated developers, CI/CD, SLA-backed support after launch

Design the API as a product from day one: versioned endpoints, authentication tokens that work for both browser and app, push notification hooks and offline-friendly data structures for field use. A mobile-first feature such as barcode scanning or GPS check-in then becomes an API call, not a second system.

Sequence matters. Build the web application and backend first, launch it, then add the mobile app once the workflows are stable; a simple app on top of an existing API is typically a 4–8 week phase.

• One backend, one database, one set of business rules
• Shared authentication and roles across web and mobile
• Mobile extras: push notifications, offline mode, camera and GPS features

Most breaches of business software come from weak passwords, over-privileged accounts and unpatched components rather than exotic exploits. That is why the boring controls matter most: two-factor login for admins, least-privilege roles, automatic session expiry, and a maintenance agreement that keeps libraries and servers patched after launch.

The security audit is part of the Professional scope. For Enterprise and regulated projects, write the audit and any independent penetration test into the scope document so they are budgeted and scheduled. If your industry requires a standard such as SOC 2 or ISO 27001, plan for it early: market data suggests SOC 2 adds 15–25% to a build.

• Access: role-based permissions, two-factor login, session expiry
• Data: HTTPS everywhere, encryption at rest, secrets kept out of code
• Code: input validation, dependency scanning, security audit before launch
• Operations: patching, monitoring, encrypted backups, tested restore

With an office in Amsterdam, Master Web scopes these requirements during discovery. Technically that means pseudonymized identifiers where possible, encryption at rest, role-based access so only the people who need a record can open it, and an audit trail of who viewed or changed personal data. Deletion must cascade through backups and integrations as well, which is why it is planned early.

Compliance is shared: the software provides the mechanisms, your organization defines the policies, the processor agreements and the legal basis for each use. Market estimates put GDPR-related work at roughly 10–15% on top of a build, far less than retrofitting it after a complaint.

• Data inventory and purpose per field; data minimization by default
• Consent records, privacy notices, cookie compliance on public pages
• User rights: export, correction and deletion flows, including backups
• Logging, retention schedules, EU-region hosting, processor agreements

Scaling problems are usually database problems. A schema designed for ten users and ten thousand rows behaves differently at a million rows. So the data model, indexing and query patterns are reviewed against realistic volumes during architecture, and a load test before launch shows where the first bottleneck appears.

Do not pay for scale you do not need yet. A single well-built application on a modest cloud instance serves most corporate systems for years. Microservices and multi-region setups are justified for SaaS products with thousands of tenants or real-time workloads, and they can be introduced later because the code is modular.

• Stateless servers, load balancing, auto-scaling groups
• Database: indexes, connection pooling, read replicas, archiving
• Caching and background queues for reports, exports and notifications
• Load testing against the expected peak before launch

Handover is a process, not a zip file. It covers a walkthrough of the architecture and the codebase for your developers, a runbook for deployment and backups, environment variables and third-party accounts transferred to your name, and a list of known limitations and planned improvements.

You are never forced to choose between us and your team. A common arrangement is a maintenance agreement for security updates and monitoring while your own developers build features; moving everything in-house is also possible, because you own the code.

• Source code, database schema and migration scripts
• Technical documentation, API reference, deployment runbook
• Deployment, scoped data migration, admin and user training
• Accounts and credentials in your company name
• Maintenance period: 3 months on Starter, 1 year on Professional

Enterprise projects add SLA-backed support with agreed response times. After the included period, a monthly maintenance agreement continues the same work: security updates, uptime monitoring, backups, small improvements and new features. The scope and response times are written into the agreement, so you know what a critical bug versus a cosmetic fix means in hours.

An SLA is only as good as its definitions. Ask any vendor for severity levels, response and resolution targets, the monitoring that detects incidents before users report them, and what happens if a target is missed.

• Included: bug fixes, security patches, monitoring during the maintenance period
• Support hours: Monday–Saturday 09:00–19:00 Istanbul time (UTC+3)
• After: monthly maintenance agreement with defined scope and response times
• Enterprise: SLA with severity levels and response targets

A rewrite is tempting and usually wrong as a first move. The old system encodes years of business rules nobody has written down, so the safer path is the strangler pattern: put a new API or interface in front, move one module at a time to the new stack, and switch the old one off when nothing depends on it.

Signs that modernization is due: the original developer is gone, security updates for the framework have stopped, deployment depends on one person, or every new feature takes months. If two of those apply, start with the audit. Market timelines for a full rebuild match a new build, 3–5 months for an internal tool.

To get a figure, bring the current system and its documentation to a free needs analysis with Master Web; the written quote follows within one business day.

• Audit: code quality, security, documentation, tests, deployability, licenses
• Refactor: keep the system, fix the worst parts, add tests and CI
• Strangler migration: new modules beside the old, switched over one by one
• Rebuild: only when the architecture itself blocks the business

In most agency contracts two things are excluded and should be stated. Open-source libraries keep their own licenses (MIT, Apache and similar, which permit commercial use), and generic internal tooling the agency reuses across projects stays with the agency, while the application built for you is yours. Neither limits your ability to run, change or sell your software.

Ownership is only useful if you can exercise it. Insist on the code being delivered to a repository you control, with build instructions, and on hosting, domain and third-party accounts registered in your company name.

• Custom code, designs and documentation: yours, in writing
• Open-source components: their own permissive licenses apply
• Repository, hosting, domain and service accounts: in your company name

Acceptance criteria are the clause people skip and later regret. Each milestone should state in testable terms what counts as done, for example: dealers can log in, see their price list and submit an order that appears in the ERP. Then sign-off is a fact rather than a feeling.

Confidentiality should cover your business data, your processes and, if you want the project unannounced, the fact of the project itself. Data processing terms matter under GDPR when the vendor touches personal data. Master Web issues a written quote that states scope and timeline, and the source code and all rights go to the client, so the contract can reference both.

• Scope document and acceptance criteria per milestone
• Change requests: procedure, estimate, written approval
• Payment schedule linked to milestones or sprints
• IP and source code ownership, open-source license note
• Confidentiality and data processing (GDPR) terms
• Maintenance, SLA, exit and handover terms

Start from a measurable process, not from the technology: where do people copy data between systems, answer the same questions, or read documents to fill in forms? Those are the automations with a payback. The model, a commercial LLM API or an open-source model hosted in your region, is chosen for cost, data policy and language quality.

Two rules keep AI features safe: personal data is minimized or anonymized before it reaches an external model, and a human approves anything that goes to a customer or changes a record. Build logging in, so you can see what the model did and why.

• Chatbot on your own documents, with handover to a human
• Document and email extraction into your ERP or CRM
• Natural-language search and reporting over business data
• Draft-and-approve workflows for replies, quotes and summaries

Where AI helps most is the repetitive layer: boilerplate, tests, documentation and migrations. Where it helps least is the part that decides whether the project succeeds: understanding your process, designing the data model and making integrations behave with real-world data. Market data still shows estimates overrun 20–35% when scope is unclear, and no tool fixes that.

AI app builders and no-code tools can produce a working prototype in days, which is useful for validating an idea. For production systems with roles, integrations and compliance, the hand-off to professional engineering still happens, so plan for it.

• Faster: boilerplate, tests, documentation, code review support
• Unchanged: discovery, architecture, integration, QA, security, compliance
• Prototype in days with AI builders; production still needs engineering

Master Web has delivered 850+ projects over 15+ years for clients in 20+ countries, with 98% client satisfaction, and works from offices in Istanbul, Amsterdam and Miami Lakes, Florida. Delivered work is listed on the references page, so you can judge the comparable-projects test before the first call.

Ask every candidate the same questions: who will actually write the code, how do they handle a change request, what do they deliver at the end, and what happens after launch. The answers reveal more than any portfolio.

• References: comparable projects, ideally a reference call
• Process: discovery, scope document, sprint demos, acceptance criteria
• Terms: code ownership, maintenance, SLA, exit clause
• Communication: named contacts, overlap with your working hours, response times
• Quote: itemized scope, assumptions, exclusions

Many companies combine the two: standard accounting and email, custom for the core operation. The same test applies to CRM and ERP. A custom CRM pays off when your sales process, pricing rules or field operations do not fit a standard pipeline, or when the per-seat licenses of a large CRM cost more than building the three modules you actually use. A full custom ERP is rarely justified; a custom layer on a standard ERP usually is.

A quick decision tree: list the five workflows that make you money, mark which ones a ready product handles without workarounds, and price the gap. If the gap is where your margin lives, that is the custom project; everything else can stay off the shelf.

• Off-the-shelf: standard process, fast start, subscription cost, limited fit
• Custom: unique process, full ownership, higher upfront cost, no per-seat fees
• Hybrid: standard tools for commodity functions, custom for the core

Time zones work for you rather than against you. Istanbul is UTC+3, so the European working day overlaps almost completely and US East Coast mornings fall inside the Istanbul support window. Calls are booked in that overlap, and the shared board carries progress and questions for the rest of your day. Inquiries get a same-day reply, and a written quote follows within one business day of the discovery call.

The process is designed to survive distance: a scope document and milestone schedule before the contract, a demo and a feedback round every sprint, and a written change request for anything new. Decisions never depend on catching someone on the phone. If you prefer to talk first, there is a US line at +1 (786) 612-9360 and WhatsApp at +90 532 655 00 95.

• Offices: Istanbul, Amsterdam, Miami Lakes (FL); English-speaking team
• Video calls for discovery, demos and reviews; shared board for progress and feedback
• Support: Monday–Saturday 09:00–19:00 Istanbul time (UTC+3)
• Same-day reply to inquiries; written quote within one business day
• US line +1 (786) 612-9360; WhatsApp +90 532 655 00 95