Development

Development in Cambodia.

Bespoke builds when off-the-shelf doesn't fit. Native mobile + REST/GraphQL APIs, fully documented and versioned. Boring, durable tech — Postgres, TypeScript, Node, Python, AWS — so your engineers can take over after go-live without a vendor escape clause. Source code yours from day one. No lock-in, no per-user fees on logic we built for you.

What does Scale's Development practice cover?

Scale's Development practice designs and builds custom software — mobile applications, APIs, back-office systems, and bespoke web products — for Cambodian operators who need software that fits their business exactly, not a configurable platform that requires the business to fit the software. Source code is yours from day one of go-live, with no per-user fees on what we ship.

Custom development is the right answer when the problem cannot be solved by configuration. When a retail chain's pricing logic is complex enough that Odoo's pricelist module would require more custom code than a clean build. When a logistics operator's dispatch algorithm needs to model road conditions that no off-the-shelf routing engine understands. When a financial services business needs a loan origination system that maps to PRAKAS requirements that no international platform was designed for. When the operational core of the business is the product — and the product needs to be owned, not rented.

Our standard technology stack: TypeScript and Node.js for back-end services and APIs (strongly-typed, easy to reason about, fast enough for every business-logic workload we have encountered), Python for data pipelines and ML adjacent work, PostgreSQL as the primary relational database (ACID-compliant, extensible, open-source, runs anywhere), React and Next.js for web front-ends, React Native for cross-platform mobile apps (iOS and Android from a single codebase, with a native-feel UI that does not look like a web wrapper), and AWS for cloud infrastructure (EC2, RDS, S3, ECS, Lambda depending on the workload).

Why this stack and not something else? TypeScript is the right language for a business-software team in Phnom Penh in 2026 because: the type system catches an entire class of bugs before they reach production, the ecosystem is the largest in the world (npm), and hiring TypeScript developers is easier than hiring developers in more niche languages. PostgreSQL is the right database because it is the most capable open-source relational database available, with excellent support for multi-currency arithmetic, JSON documents alongside relational tables, and row-level security for multi-tenant systems. React Native is the right mobile framework for most Cambodian business apps because the business logic and API layer can be shared with the web front-end, cutting development cost by 30–40% compared to separate native builds.

Source code ownership is a first-principle of how we work. Every project ends with a full repository handover — code, deployment configuration, infrastructure-as-code, CI/CD pipeline, and a deployment runbook — transferred to a client-controlled repository on the day of go-live. We do not retain source code, we do not hold deployment credentials, and we do not structure engagements so that you need to call us to deploy a bug fix. You own the software. We build it, hand it over, and offer ongoing support if you want it.

When should you build custom versus buy off-the-shelf?

Build custom when the operational logic that differentiates your business cannot be represented without destructive workarounds in a configurable platform. Buy off-the-shelf when the business process is standard and the platform's configurability covers your real requirements — not just the requirements you think you have before you use the platform.

The honest answer to 'build vs buy' is that most businesses overestimate how unique their requirements are. An accounting system is an accounting system. A CRM is a CRM. The functional requirements of 80% of Cambodian SMBs in these domains are well-served by Odoo or SAP Business One with Cambodia-specific configuration. The argument for custom development in these cases is usually not correct — it is driven by familiarity with a legacy system, or by a reluctance to change processes to fit a better-designed workflow.

But the 20% where custom is genuinely right is real. The decision framework we use with clients: Does the business have operational logic (pricing, routing, workflow, compliance) that a configurable platform cannot represent without bending its data model in ways that will break the platform's built-in reporting? Is the proprietary operational logic the thing that makes the business competitive — i.e., is it the product? Does the business have the internal technical capability to own and operate the software after handover (even with our support retainer)? Is the total cost of bespoke development over 3 years lower than the total cost of per-user licensing, configuration maintenance, and workaround overhead in an off-the-shelf platform?

Lock-in is a real consideration in both directions. Off-the-shelf platforms lock you in to their data model, their API rate limits, their pricing changes, and their product roadmap decisions. Custom software locks you in to the technology choices made at build time and the quality of the engineering team that built it. The way to mitigate custom software lock-in: use open-source, standard technology (TypeScript, PostgreSQL, React — not proprietary frameworks); insist on source code ownership from go-live; insist on a deployment runbook that lets another engineering team take over; and negotiate a support retainer that is month-to-month, not locked.

Maintenance burden is the most underestimated cost of custom software. A well-built system on a standard stack requires approximately 10–15% of the initial build cost per year in maintenance (security patches, dependency updates, minor feature additions, bug fixes). A poorly-built system on a bespoke or non-standard stack can cost 30–50% of the initial build cost per year in maintenance just to keep running. We build on standard, well-supported stacks precisely because it minimises your long-term maintenance burden.

How long do development projects take?

A typical SMB custom development project — a business-logic API and admin dashboard, or a mobile app with a back-end — runs 8–16 weeks from signed contract to production deployment. Complex mid-market products with multiple user roles, offline mobile capability, and multi-entity data models run 16–32 weeks.

The most common cause of development project overruns is scope change — new requirements added after the specification is locked. We manage this through a formal change-order process: any new requirement that is not in the specification is documented, estimated, and quoted as a change order before any development work starts on it. This keeps the project on schedule and gives the client full visibility of cost for scope additions.

  • Discovery (Weeks 1–2): Requirements workshops, user-story mapping, API contract design, data model design, third-party integration scoping (banking, GDT, ERP). Output: a fixed-scope specification document.
  • Design (Weeks 2–4): UX wireframes and user flows (Figma), database schema finalised, API routes defined, component library decisions. For mobile: platform-specific interaction design for iOS and Android.
  • Build (Weeks 4–14): Backend API development (TypeScript/Node, Postgres), front-end development (React or React Native), integration adapter development (if in scope), unit and integration tests written alongside code. Weekly demo to client against agreed spec.
  • Test + QA (Weeks 12–16): End-to-end test run by QA engineer on staging environment. Performance testing for high-volume operations. Security review (authentication, authorisation, input validation, SQL injection prevention). UAT by client team on staging.
  • Launch (Weeks 14–18): Production deployment on AWS. DNS cutover. Monitoring and alerting configured. Performance baseline recorded. Hypercare period begins.
  • Handover (Week 16–18): Repository transfer to client. Deployment runbook delivered. Infrastructure credentials transferred. CI/CD pipeline documented and handed over.

What does Custom Development cost in Cambodia?

An SMB custom development project — a standalone business API, admin panel, or mobile app — typically runs $10,000–$50,000 on a fixed-scope basis. Mid-market products with complex data models, multi-role access control, and multiple integrations run $50,000–$200,000. Prices reflect fixed scope after a paid discovery sprint.

The cost determinants for custom development are: front-end surface (admin panel only is cheaper than admin panel plus customer-facing web plus mobile app), back-end complexity (a simple CRUD API is cheaper than a multi-tenant system with row-level security and complex business rules), integration count (each bank, GDT, or third-party API integration adds $2,500–$8,000 to scope), quality requirements (test coverage, security review, performance testing all have a cost — and all have a cost when omitted too, just later), and post-launch support included in the initial quote.

We quote fixed scope, fixed price after a paid discovery sprint. Discovery runs 1–2 weeks and costs $800–$1,500 (deducted from the project fee if you proceed). The output is a full specification document, a data model diagram, an API contract, and a fixed quote with a scope boundary. Hourly estimates for custom development are not credible; they invariably underestimate complexity and create misaligned expectations. Fixed scope is the only model that gives both sides clarity.

Ongoing costs after delivery: AWS infrastructure for a typical SMB back-end runs $80–$300/month depending on compute, storage, and traffic. Database hosting on RDS runs $60–$200/month. A managed support retainer from Scale — covering security patches, dependency updates, and bug fixes — runs $500–$2,000/month depending on system complexity. The support retainer is month-to-month; there is no long-term lock-in.

What stacks do we use and why?

We build on TypeScript, Node.js, PostgreSQL, React, React Native, and AWS — chosen for ecosystem size, hiring access in Southeast Asia, long-term maintainability, and Cambodia-specific operational requirements. Every technology choice is documented in the handover package with the rationale, so the next team inheriting the codebase understands why decisions were made.

TypeScript over JavaScript: TypeScript's static type system catches interface mismatches, null pointer errors, and incorrect API response shapes at compile time — not in production at 2am. For business-software systems where correctness matters (financial calculations, inventory quantities, user access control), the type system is not optional. Every module we ship is written in strict TypeScript with no unsafe casts.

Node.js over other back-end runtimes: Node's event loop handles I/O-bound workloads (API calls, database queries, file operations) efficiently with low memory overhead. The npm ecosystem covers every integration library we need. The language is the same as the front-end, reducing context-switching for full-stack engineers. For CPU-bound workloads (ML inference, image processing, heavy data transformation), we use Python microservices alongside the Node API layer.

PostgreSQL over other databases: PostgreSQL handles multi-currency arithmetic correctly (NUMERIC type, not FLOAT), supports JSON documents alongside relational tables (JSONB), has row-level security for multi-tenant systems, and runs identically on a developer's laptop, a Render instance, or AWS RDS. We have never encountered a business-software workload that PostgreSQL cannot handle. We do not use MongoDB or other document databases for business-logic applications — their lack of ACID guarantees on multi-document transactions is incompatible with financial data correctness.

React Native over native iOS/Android: A single React Native codebase produces both iOS and Android apps that share the business-logic layer and the API client. For most Cambodian business apps — field service, warehouse, sales rep, customer-facing — the performance is indistinguishable from fully native. The cost saving versus two separate native codebases is 30–40%. We use React Native's new architecture (Fabric renderer, TurboModules) for production apps; not Expo managed workflow for anything requiring custom native modules.

AWS over other cloud providers: AWS has the most mature managed service offering (RDS, ECS, Lambda, S3, CloudFront) and the most complete Cambodian developer hiring base. We avoid AWS proprietary services where possible (preferring Postgres on RDS over DynamoDB, ECS over Lambda for always-on services) to keep the codebase portable to other providers if needed. Infrastructure is defined as code (Terraform or CDK), not clicked-through in the console.

What about ownership, IP, and source code?

Source code is yours from the day of go-live — transferred to a client-controlled repository with no strings attached, no licence fees, and no ongoing dependency on Scale to deploy or modify it. Intellectual property created during the engagement is assigned to you in the contract, not licensed to you.

We have a clear position on this: the software we build for you is yours. Not licensed to you under a recurring fee. Not hosted by us with a clause that gives us leverage. Yours. The contract is written to reflect that. The git repository is transferred to your GitHub, GitLab, or Bitbucket organisation on go-live day. The deployment credentials (AWS IAM, domain registrar, SSL certificates) are transferred to you simultaneously. The monitoring and alerting tools are configured on your accounts, not ours.

The handover package includes: the full source code repository with commit history, a deployment runbook (step-by-step instructions to deploy the system from scratch, including all environment variables and secrets management), an infrastructure-as-code repository (Terraform or CDK) for the AWS resources, a CI/CD pipeline configuration (GitHub Actions or similar) that runs tests and deploys automatically on merge to main, and a system architecture document covering the data model, API routes, integration points, and key design decisions.

No per-user fees on bespoke logic. If we build a CRM for your sales team, you do not pay per seat. If we build a warehouse management app for 20 warehouse staff, there is no $X/user/month charge. The software is yours and the cost of running it is AWS infrastructure (charged by usage, not by user) plus whatever support retainer you choose. This is a fundamental difference from SaaS platforms — and it is why custom development makes economic sense for businesses above a certain scale or with specific operational requirements.

Reuse of generic components: we do maintain a library of generic infrastructure components (authentication modules, multi-currency arithmetic utilities, API client patterns, monitoring scaffolding) that we reuse across client projects. These components are not proprietary to any single client — they are general-purpose code that we have developed over multiple engagements. The contract is clear on this: generic infrastructure components are shared; business-logic code written specifically for your engagement is yours exclusively.

FAQ

Frequently asked questions — Development

  • Do we need an in-house technical team to hand over the software to?

    No. Most of our clients do not have in-house technical teams at the time of go-live. The deployment runbook is written for a non-technical operations manager to hand to any competent developer — it does not require Scale-specific knowledge. For ongoing maintenance, we offer a month-to-month managed support retainer covering security patches, dependency updates, and bug fixes. You can cancel the retainer at any time and bring the work in-house or to another provider — the handover package has everything they need to take over.

  • Can you build mobile apps that work offline in areas with poor connectivity?

    Yes. Offline-first mobile architecture is a specific requirement for field-service, logistics, and agricultural businesses operating in areas of Cambodia with intermittent connectivity. React Native with a local SQLite or Realm database can cache data locally and sync to the back-end when connectivity is available. The sync logic — conflict resolution, last-write-wins vs. merge strategies, partial sync for large datasets — is the complex part and is scoped explicitly in discovery. We have built offline-first apps for field survey collection, delivery confirmation, and agricultural input distribution.

  • How do you handle Khmer language in mobile and web apps?

    Khmer (Unicode block U+1780–U+17FF) requires specific font and rendering support. We use Noto Sans Khmer or Battambang for body text and custom Khmer-compatible fonts for headings where brand identity requires it. React Native's text rendering handles Khmer correctly on both iOS and Android without third-party libraries. Line-breaking and text wrapping are tested explicitly for Khmer strings, which behave differently from Latin text. Date formatting, number formatting (KHR with Khmer numerals if required), and right-to-neutral layout are all handled in the internationalisation (i18n) layer.

  • Can you build on top of an existing codebase we already have?

    Yes, with a code audit first. Before committing to extending an existing system, we conduct a 1-week paid code audit ($800–$1,500) covering: technology stack and dependency versions, test coverage, security posture (authentication, authorisation, input validation, secrets management), database schema quality, and deployment infrastructure. The audit output is a technical debt register and a recommendation: extend as-is, refactor-then-extend, or rebuild. We do not extend codebases we have not audited — inheriting unknown technical debt without visibility is how projects overrun.

  • What happens if we need a feature added after go-live?

    Post-launch feature additions are handled as new scoped engagements — same process as the original project: discovery sprint to specify the feature, fixed quote, build, test, deploy. This keeps the cost visible before any work starts. Bug fixes (defects in the original scope that surface after go-live) are covered under a 90-day warranty period at no additional charge. After 90 days, bug fixes are covered by the managed support retainer if you have one, or quoted as small change orders if you do not.

  • Do you build APIs that other developers can integrate against?

    Yes. Building a well-documented, versioned REST or GraphQL API for third-party or internal integration is a common scope for our Development practice. The API ships with: OpenAPI (Swagger) documentation published at /api/docs, versioned routes (v1, v2) with a deprecation policy, authentication via JWT or API key depending on the consumer, rate limiting and quota management, and a sandbox environment for integration partners to test against. We also build the SDK or integration guide if the API will be consumed by external partners.

  • Can you help us with AI or ML features inside a custom application?

    Yes — with a clear scope boundary. We build AI features that have a defined input/output contract and a clear business purpose: document classification, invoice data extraction (OCR plus LLM), predictive reorder point calculation, chatbot FAQ response for a known knowledge base. We do not build speculative ML research. The AI components are built as microservices (Python, FastAPI) that plug into the main TypeScript application via a defined API contract, so the AI layer can be updated or replaced without touching the rest of the system. See /services/ai-data for the AI practice scope.

  • What is your policy on open-source libraries and licences in our codebase?

    We use open-source libraries extensively (it would be impractical not to), and we document every dependency's licence in the handover package. We avoid libraries with GPL or AGPL licences in commercial codebases (these licences can require the entire application to be open-sourced if the library is included — rarely the client's intention). We prefer MIT, Apache 2.0, and BSD-licensed libraries. For any library where licence compliance is ambiguous, we flag it in the code audit or discovery and either find an alternative or get an explicit legal sign-off from the client.

Not sure where to start? Two-week paid discovery answers it.