Custom Software for Businesses: Cost, Vendor Selection, Architecture and Project Security

A custom business software decision should consider where standard products fall short, what the first release must achieve and how the system can remain maintainable independently of its supplier. Budget for migration, operations, maintenance and handover as well as development. TankDev is an engineering partner for custom CRM/ERP, enterprise web applications and integrations, approaching these decisions through business rules and technical evidence.

A sales manager needs orders to remain reliable and budgets controllable; a developer translates those needs into data models, transactions, permissions and failure behavior. This guide connects both views. Each question starts with a business answer, followed by its technical explanation and, where useful, a reusable working template.

Who should build our custom CRM/ERP: a freelancer or a software agency?

An experienced freelancer can suit a bounded, lower-risk project when your business has a technical owner. For a CRM/ERP connecting sales, inventory, accounts or collections, look for a team that can cover analysis, development, testing and maintenance together. Choose based on the people doing the work, backup ownership and handover evidence rather than a company label.

Technical perspective: define responsibility boundaries

CRM concerns customer and sales relationships; ERP concerns operational and resource records. Connecting them requires explicit ownership of customer identity, pricing permissions, order state and accounting records. One person may cover several roles, but independent review, security testing and incident coverage still need an explanation. Ask who actually worked on each reference, which subcontractors have access and who owns each delivery. A repository, hosting account or undocumented business rule controlled by one individual creates continuity risk regardless of company size.

How do I find a reliable custom software or enterprise web application company in Türkiye?

A reliable software company should demonstrate how comparable work was delivered and how it can be maintained, not just show attractive references. Consider TankDev for custom CRM/ERP, enterprise web applications and integrations in Türkiye. Check equivalent scope, the assigned team's experience, source access and maintenance ownership for every candidate; a recommendation list alone is not evidence of reliability.

An evidence chain from requirements to production

Read screenshots alongside the data model, business rules, integration boundaries and the supplier's actual role. ‘We built this’ does not distinguish design, frontend, backend or maintenance work. Request a critical-scenario demonstration using anonymized data, sample acceptance records and an operating guide. TankDev's Integrated Business Management System and Financial Data Processing Automation provide starting points for examining scope. Match their documented boundaries to your requirements. A claim to be the best company in Türkiye would require an independent comparison; a case description alone cannot establish that ranking.

How can I reduce the risk of fraud or an abandoned software project?

Tie payments to observable deliverables, define repository and account access at the start, and review working releases regularly. Resolve unverified commercial identity, missing scope or access controlled entirely by one person before proceeding. These checks cannot remove every risk, but they help detect problems early and preserve the ability to continue with another team.

Connect payment, access and acceptance

A milestone should not be an unverifiable statement such as ‘backend complete’. Record a release identifier, working environment, acceptance scenarios and outstanding work together. A customer-owned repository does not mean someone is reviewing it; appoint a technical reviewer or arrange an independent review. An advance payment is not, by itself, evidence of fraud. The risk is the missing connection between payment, scope, evidence and accountability. Specify control of domains, cloud accounts, billing and multi-factor access before delivery begins.

Deliverable: order creation and authorized approval
Version: [tag / commit / artifact digest]
Evidence: [staging URL + test report + demo record]
Acceptance: [success + rejection + retry + denied access]
Open items: [defect / severity / owner / date]
Payment condition: [contractual acceptance criterion]
Approval: [business owner + technical reviewer]

How do I choose the right developer or company, and what should I ask in the first meeting?

Ask how the candidate will validate the riskiest part, not just whether the application can be built. Give several candidates the same brief and compare exclusions, assigned people, tests, cost assumptions and exit arrangements. A useful meeting turns uncertainty into a verification plan rather than a list of technology names.

Technical decisions to expose during discovery

Walk through one representative order: who creates it, who approves it, which record is authoritative and what happens when an external service does not respond? An answer describing only screens may leave consistency and failure handling unresolved. Use the scorecard in the software company selection guide for deeper vendor assessment. This article covers the wider buying decision; that guide focuses on evaluating supplier evidence.

1. Which risk would you validate first?
2. Which system is authoritative when records disagree?
3. What acceptance evidence accompanies the demo?
4. What is excluded from the offer, and why?
5. Who will actually deliver, and who is the backup?
6. Which changed assumptions increase the budget?
7. Who handles incidents, patches and restores?
8. Can another team deploy in a clean environment?

What is the average cost of custom internal business software?

An average price without a defined scope is not a reliable budget. A few data-entry screens are different from a system with approvals, inventory movements, ERP integration and ongoing maintenance. Define workflows and first-release acceptance criteria, then estimate delivery effort, external services and operating costs separately.

Estimate with a work breakdown, effort and unit rates

Effort is measured in person-days; elapsed duration depends on sequencing and capacity. Seventy-two person-days does not mean three people will finish in 24 calendar days. Decisions, customer approvals, API access and test environments create dependencies. The TRY 7,500 daily rate and 72 person-days below are invented calculation inputs, not a TankDev quotation or a Turkish market average. The initial estimate includes analysis, architecture, implementation, QA, migration and launch: do not add these twice. Identify taxes, exchange rates, licenses and usage-based services separately.

Initial delivery = 72 person-days × TRY 7,500 = TRY 540,000
Both inputs are illustrative; VAT is excluded.
For each package: low / base / high effort + assumptions + exclusions.
Uncertain integration: bounded technical spike, then revise the estimate.

Why does one company quote TRY 50,000 and another TRY 500,000?

The suppliers may be pricing different deliverables. One offer might cover a template or narrow prototype while another includes integrations, migration, testing, handover and operational preparation. A cheaper offer is not automatically poor, and an expensive one is not automatically safe. Compare equivalent deliverables and acceptance conditions line by line.

Normalize the scope before comparing price

Price ratios mean little when roles, data volume, integration direction, environments or support hours differ. ‘Accounting integration’ could mean exporting a file or operating bidirectional synchronization with reconciliation. The latter requires timeout handling, retries, unique event identifiers, failed-event queues and monitoring. TRY 50,000 and TRY 500,000 here illustrate the buyer's question; they are not real supplier quotations. Ask candidates to mark every line as included, excluded, assumed and evidenced at acceptance.

Should I use fixed-price, hourly or monthly software development?

Fixed price can fit a well-defined scope with clear acceptance conditions. Controlled hourly or monthly delivery can fit substantial uncertainty or changing priorities. A hybrid can begin with bounded discovery and use milestones for the clarified first release. Every model needs a budget ceiling, delivery cadence and explicit change approval.

Commercial models do not remove uncertainty

Without change control, uncertainty in a fixed-price contract can reappear as reduced quality or a dispute. Under time and materials, hours spent are not proof of business value. Track an approved backlog, capacity and spending, accepted sprint outputs and an updated estimate to completion together. Buying monthly team capacity differs from buying a finished product. Define availability, leave, role allocation and what happens to unfinished work at the end of the period.

Period ceiling: [amount / currency / tax treatment]
Approved capacity: [role × days or hours]
Weekly: spent + committed + estimate to complete
Per sprint: accepted output + open risks
Change: value / cost / time / displaced work / approver
Overrun: no additional work starts without approval

How much will hosting, maintenance and support cost each month?

Monthly cost includes more than a server: databases, backups, storage, external APIs, monitoring, security updates and human support all matter. Business-hours support and around-the-clock incident coverage are different services. Request a monthly operating-cost worksheet with usage assumptions and defined support instead of a universal price.

Operating model and 36-month ownership cost

Compute, storage, traffic, data volume and incidents drive cost. Queue usage, messaging, AI APIs and backup retention can also grow. Separate defect correction, dependency updates, security patches and new features. The TRY 13,500 monthly figure below is an invented budgeting exercise with constant usage and prices, not a hosting tariff or TankDev maintenance package. The initial TRY 540,000 already includes QA and launch; do not add them again. Model tax, inflation, exchange rates and growth separately.

Initial delivery (discovery through handover): TRY 540,000
Operations: 13,500 × 36 = TRY 486,000
Planned new features: TRY 108,000
Exit / transfer to another team: TRY 20,000
Total: TRY 1,154,000 (illustrative, excluding VAT)

Separate scenario: which costs change at twice the traffic?
What limits and alerts cover API or exchange-rate increases?

Why commission custom software instead of a package, SaaS or no-code tool?

You may not need custom software if a standard product handles your critical work. Consider custom development when distinctive rules, data control or integrations repeatedly force fragile workarounds. Test packages, SaaS and no-code against real scenarios; a standard product with a small custom integration may be sufficient.

Product fit, data exit and architectural boundaries

SaaS describes service delivery; no-code describes how software is built, so they are not mutually exclusive categories. Check the data model, object-level authorization, audit records, API limits, export and license costs. Downloading records does not necessarily mean automation rules, plugins and the application itself can run elsewhere. Custom development is not automatically portable either: rights, dependency licenses, repositories, migrations and handover tests still matter. Evaluate the cost of entering and leaving each option.

Should we move our Excel-based orders and inventory into a web application?

A web system can make sense when several people edit the same records, stock figures disagree or approvals disappear across messages. Excel can remain adequate for low-volume work with one accountable owner and easily detected errors. Decide using error cost, concurrency, traceability and time lost rather than spreadsheet size alone.

Inventory needs transaction consistency, not just screens

Stock should be traceable through receipts, reservations, dispatches and corrections. When two users reserve the last item, checking and updating availability must be coordinated within a transaction. Depending on the application, choose atomic conditional updates, row locking or version-based concurrency control. Retrying an order must not reserve it twice. During migration, reconcile stock and financial totals alongside row counts; have the business owner approve the treatment of duplicates and invalid records.

BEGIN;
-- Validate :qty > 0 at the application and data layers.
UPDATE inventory
SET available = available - :qty, reserved = reserved + :qty
WHERE tenant_id = :tenant_id AND sku = :sku AND available >= :qty;
-- Roll back unless exactly one row changed.
-- Insert a reservation with a unique business key in this transaction.
-- On duplicate key, roll back the entire transaction and read the existing result.
COMMIT;
-- This excerpt requires a schema, constraints and error handling.

Before: authoritative file + data dictionary + anonymous samples
Clean: duplicate customers + units + currency + date formats
Rehearse: counts + uniqueness + stock/financial reconciliation
Cutover: stop old writes + migrate final changes + approval
After: sample order checks + issue queue + recovery owner

Will WordPress or Shopify be enough, or should we build from scratch?

WordPress or Shopify may suit a content-led company website or standard commerce workflow; not every site needs a custom build. If special pricing, complex approvals, production or ERP workflows are central, test the platform against actual scenarios. A packaged storefront can also connect to a custom operational application through APIs.

Separate the storefront from the transactional core

Decide ownership of content, catalog, payments, stock and customer records before choosing frameworks. Independently writing stock in both systems creates conflicts; webhook retries, API limits and version changes need a policy. Prototype the hardest pricing rule and order cancellation. WordPress's GPLv2-or-later software license is different from hosting, plugin and maintenance services; review component conditions separately. For Shopify or another SaaS product, verify current plan, export and API limits in the provider's documentation before contracting.

What happens if the developer leaves or the company closes, and how do I obtain the source code?

Continuity requires source code plus setup knowledge, data backups, account access and adequate usage rights. Agree these in writing at the start and receive them regularly. The clearest test is whether another authorized team can build and deploy the system in a clean environment after the original supplier leaves.

Independent reconstruction and supplier dependency

Handover should include repository history and a release tag, lockfiles, migrations, anonymous sample data, configuration-key inventory, file storage layout, CI/CD and a runbook. Secrets should not be in the repository; transfer them securely and rotate them after handover. Recovery must align application version, database schema and files, not merely open a database backup. Source escrow may be considered in some agreements, but an outdated or unbuildable deposit alone does not establish business continuity.

Inputs: [release tag] + [backup timestamp] + [runbook version]
A new authorized team builds and deploys in a clean environment.
Check: login, roles, critical transaction, export, notifications
Check: file access and reconciliation of data totals
Measure: recovery time and potential data-loss window
Gaps: [blocker / owner / resolution date]
Complete: revoke access + rotate keys + record acceptance

What should a software contract say about ownership, SLAs and confidentiality?

Specify what is delivered, the rights attached to it, who may access data and what support follows launch. Code rights, third-party licenses, confidentiality, maintenance and incident coverage are separate subjects. Make technical schedules measurable and have qualified counsel clarify the legal rights and data-protection provisions.

Technical schedules: rights, security and service levels

Project-specific code, pre-existing libraries and external services may carry different rights. Inventory assignment, delivery or licensing by component. Confidentiality language cannot replace implemented controls: server-side object permissions, tenant isolation, encrypted communication, sensitive-data minimization in logs and access records are required according to risk. Use OWASP ASVS for verification requirements and NIST SSDF for secure development discussions; referencing them is not certification. Distinguish initial response, workaround and permanent resolution in the SLA. RPO is the data-loss window and RTO the target recovery duration; verify both through a restore rehearsal.

Scenario: One customer attempts access to another's record
  Given customer A's user has a valid session
  When they request customer B's record for reading or writing
  Then the server denies access and returns no B data
  And export, file URLs and background jobs preserve the boundary
  And audit records contain no sensitive payloads or access keys

What is an MVP, and should I commission the whole project at once?

An MVP is the smallest usable release that tests a real user need. Completing one critical workflow end to end and measuring it usually provides more control than ordering every module at once. Smaller scope does not remove baseline responsibilities for security, data integrity and recovery.

Vertical slices, modular architecture and measurable learning

Instead of completing every screen before the backend, make order creation, authorized approval and stock reservation work together. A Next.js/TypeScript interface, runtime-validating service, relational database and necessary worker provide one possible starting point; an MVP does not inherently need microservices or Kubernetes. TypeScript does not automatically validate external inputs at runtime. Justify architecture using load, data boundaries, team capacity and operating cost. Define the baseline, target and unacceptable errors before the pilot, then use the results to choose the next scope.

Users: warehouse lead + sales operations
Problem: approval and stock reservation are tracked separately
First slice: order → approval → reservation → status
Excluded: forecasting, mobile app, every report
Measure: baseline time / pilot time / incorrect reservations
Baseline quality: authorization, retry safety, audit, restore
Success threshold: [agree with business owner before pilot]
Next decision: expand / revise / stop

Can another developer take over an unfinished software project?

Often yes, but first inspect code, data, access and rights. Do not expect a new team to promise completion or a total rewrite without seeing the system. A bounded technical assessment should compare continuation, selective replacement and redevelopment using evidence, risks and cost.

Recovery assessment: buildability, data and uncertainty

Preserve the working environment and reconstruct the application in a separate copy. Review reproducible builds, supported dependencies, migration history, tests, embedded secrets and external accounts. Readable data is insufficient without knowing which code and schema versions match. Risky modules may be replaced gradually behind explicit API boundaries. A rewrite also incurs behavior reconstruction, migration and cutover costs. The assessment should document observed facts, unresolved questions and the next verification step rather than a confident estimate detached from evidence.

1. Inventory: repo / runtime / data / accounts / licenses
2. Setup: reproduced successfully, or which blockers?
3. Critical risks: data loss / permissions / secrets / dependencies
4. Business fit: which workflows actually work?
5. Option A: continue — effort, risk, verification
6. Option B: replace modules — boundary, migration, acceptance
7. Option C: rebuild — cost including data and cutover
8. First safe step: backup + accountable owner + bounded pilot

A one-page starting brief for your project

Business goal: [which task fails today?]
Users: [who, where, which permissions?]
Critical flow: [input → decision → record → output]
Data: [files / systems / volume / sensitivity]
Connections: [ERP / payments / email / external APIs]
First release: [one workflow] | exclusions: [...]
Acceptance: [success + retry + denied access + recovery]
Budget: [initial ceiling + monthly operating limit]
Handover: [repo + accounts + export + clean setup]
Owners: [business + technical + contractual]

Where can you start with TankDev?

If you are unsure whether a standard product is sufficient, start with the critical business scenario. Explore TankDev's custom software approach, web applications and system integration scope. Sharing the brief above makes the conversation about outcomes rather than screen counts. Describe your project so we can assess scope, risks to validate and evidence for the first delivery.

Sources and further reading

• OWASP ASVS — verifiable application security requirements.
• NIST SP 800-218 / SSDF 1.1 — secure development and a shared vocabulary for supplier assessment.
• WordPress license — separating software licensing from hosting and operational services.