Frequently Asked Questions

True Dev is a software development company that builds custom software, web applications, mobile apps, system integrations, IoT solutions, and AI tools. We operate as an end-to-end technology partner — handling design, development, testing, security, SEO, and ongoing support — for organizations that want thoughtful execution across the full delivery lifecycle.

Our delivery operations are headquartered in Bangkok, Thailand. We serve clients globally across North America, Europe, and Asia, with workflows and availability structured around international business hours.

Our current delivery operations are headquartered in Bangkok, Thailand. Over the course of our history we have also operated out of New York City and Stockholm, and that international footprint continues to shape how we work — with processes, availability, and client communication aligned to global business standards.

True Dev is Swedish-owned and founder-led. The founder has been working professionally in design, full-stack software development, and AI since 1997 — approximately 30 years of hands-on commercial experience. Swedish ownership combined with a Bangkok-based delivery team is a deliberate part of how we operate.

The founder has been delivering commercial software projects since 1997. True Dev continues that track record with a team structured around senior technical leadership and modern delivery practices.

Three things. First, we treat technology as a means to business outcomes — every project is evaluated on the value it delivers, not just the features it ships. Second, we cover the full delivery lifecycle: design, development, security, SEO, testing, and long-term support. Third, our leadership has worked in this industry since 1997, which means decisions are made with perspective, not guesswork.

We work with organizations that prioritize technology as a strategic asset — companies looking for a partner with deep experience who can deliver smart solutions that make them more competitive and more attractive to their own customers. Our clients range from startups to well-established enterprises across the full spectrum. The common thread is mindset, not company size.

We work with clients in approximately 30 countries across North America, Europe, and Asia. Our operations are well-aligned with European business hours, and for clients in North America we routinely structure workflows to support a daily sync during US morning hours when the engagement requires it.

Client communication is conducted in English and Swedish. For the software itself, our engineering capability is language- and framework-agnostic — details are in the Technical section.

We operate as a focused delivery organization structured around each engagement rather than a headcount-driven agency. Team composition on any given project is matched to scope — from a single specialist for targeted work to cross-functional teams of designers, developers, and QA engineers for larger builds.

Both. We work with startups that have validated their concept and have funding or revenue to sustain a development engagement, and we work with well-established companies including large international brands on defined scopes of work. We do not take on speculative pre-funding builds or equity-only arrangements.

Leadership has been active in the industry since 1997. The wider team is composed of mid-level to senior engineers and designers. We do not staff client projects with juniors learning on your budget — every billable role is accountable for output quality.

Yes. We act as a white-label or subcontracted delivery partner for agencies that need additional capacity or specific technical expertise, alongside our direct client work. White-label engagements are covered by NDA and clearly defined IP agreements from day one.

We have delivered projects across a wide range of industries over the years. We have particular depth in dating, delivery, e-commerce, security, real estate, and photography — sectors where our team has not only delivered client work but also built and operated our own products and businesses. That operator-side experience shapes how we approach client projects in these areas.

Both. Many clients begin with a defined project and transition into an ongoing support or retainer arrangement once the initial build is live. Others engage us for a single, well-scoped delivery. Both models are supported — commercial structure is covered in the Pricing section.

The strongest fit profile is an organization that treats technology as a strategic investment, wants a partner who takes responsibility for the full delivery lifecycle, and values experience over the lowest price. The fastest way to find out is a short discovery call — we will tell you directly if your project is outside our sweet spot.

We deliver custom software development, web applications, mobile apps, system integrations, IoT solutions, AI tools, and digital transformation engagements. Each project is supported by design, security, SEO, testing, and ongoing maintenance as part of the full delivery lifecycle — not treated as optional add-ons.

We build custom software. Our value lies in solving problems that off-the-shelf products do not address — integrations between systems, workflows specific to your operation, or entirely new products. When an off-the-shelf solution is genuinely the better option for a client, we will say so.

Yes. Design is an integrated part of how we work, not a separate service bolted on. Every project includes UX and UI considerations from the beginning, with production-grade design delivered alongside development. Good design is a commercial asset, and we treat it that way.

Yes. SEO is built into our web development process — technical SEO, performance, structured data, accessibility, and content architecture are considered from the start rather than retrofitted afterward. We treat SEO as a core part of shipping a website that performs commercially.

Yes. We build native and cross-platform mobile applications for iOS and Android. App-specific questions — including approval timelines, platform compliance, and quality assurance — are covered in the App Development section.

Yes, extensively. AI is one of our core competencies, and we build AI tools, AI-integrated applications, and AI-driven automation for clients across industries. How we approach AI development — and why it requires more than prompt engineering — is covered in the AI & Modern Development section.

Yes. System integration is one of our most common engagement types — connecting CRMs, ERPs, payment processors, accounting tools, analytics platforms, and custom databases. We handle both modern API-based integrations and bridging to legacy systems where required.

Yes. We deliver IoT solutions covering device connectivity, data pipelines, dashboards, and cloud backends. IoT projects often combine hardware firmware interfaces, cloud infrastructure, and web or mobile frontends — and we handle the full stack.

Yes. Digital transformation engagements typically start with understanding current operations and where technology can create measurable business value, then move into delivery. We focus on practical transformation — software that changes how work gets done — rather than strategy documents that never ship.

Yes. We build e-commerce solutions ranging from custom storefronts to platform-based implementations, integrated with payment providers, inventory systems, and fulfillment workflows. E-commerce is one of the industries where we also have operator-side experience.

We design, deploy, and manage cloud infrastructure as part of our projects — typically on AWS, Google Cloud, or Azure depending on the engagement. For clients who prefer to own their hosting relationship, we structure deployments so ownership can be transferred cleanly. See the Technical section for more detail.

Yes. QA is part of every engagement, not an optional line item. We cover functional testing, integration testing, performance testing, and security testing. For clients with compliance requirements, we can align QA processes with specific standards.

Yes. We provide security auditing as both a standalone service and as part of development engagements. Our work covers OWASP Top 10, dependency and code auditing, secret scanning, container and infrastructure scanning, and network assessment. Further detail is in the Security, Privacy & Compliance section.

Yes. Post-launch support is available as structured support agreements with defined response times and monthly scope. Many clients transition into a retainer relationship after the initial delivery. Details are in the Support & Maintenance section.

We do not develop games, and we do not produce hardware. Everything else within commercial software — web, mobile, backend, AI, integrations, IoT software layers — is within our scope. If you are unsure whether your project fits, a short discovery call will give you a clear answer.

Yes, and this is a common engagement type. We begin with a technical audit of the existing codebase and infrastructure to understand what can be preserved, what needs refactoring, and what should be replaced. We will give an honest assessment before committing to scope.

Yes. Legacy migration is one of our recurring engagement types — from older frameworks and databases to modern, maintainable architectures. We handle data migration, parallel operation during transition, and decommissioning of legacy systems.

Yes, extensively. AI is one of our core competencies — we build AI tools, AI-integrated applications, intelligent automation, and AI-driven features embedded in broader software products. Our approach treats AI as an engineering discipline, not a buzzword.

We build custom chat interfaces, AI agents, document and data processing pipelines, retrieval-augmented generation systems, AI-assisted internal tools, model fine-tuning workflows, and AI features embedded inside larger products. We also integrate commercial AI APIs where that is the right commercial choice, and build proprietary capabilities where it is not.

We work across the major AI platforms including Anthropic (Claude), OpenAI, Google, and open-source models where they are the right fit. Model selection is an engineering decision based on the task, cost, latency, and data requirements — not brand preference.

There is a common misconception that AI removes the need for engineering expertise. The opposite is true. Building production AI systems requires deep understanding of database design, system architecture, security, testing, and data flow — combined with knowing what to ask an AI to build in the first place. Without that foundation, AI output is fragile, insecure, and expensive to maintain. The tools have changed; the engineering discipline has not.

Production AI development requires the same skills as any serious software engineering — database architecture, API design, security, performance, testing, and system integration — plus AI-specific knowledge of prompt design, context management, retrieval systems, evaluation, and cost optimization. Missing any of these layers results in systems that demo well but fail in production.

AI tools amplify the capability of experienced engineers and expose the gaps of inexperienced ones. An AI can generate code quickly, but deciding *what* to build, how it should be architected, how data flows, how it stays secure, and how it behaves under real load — those decisions still require human judgment built on years of experience. The cost of fixing a badly designed AI-generated system typically exceeds the cost of building it properly from the start.

We treat AI-generated code the same way we treat any code — it goes through architecture review, security audit, testing, and human engineering oversight before it reaches production. AI is a productivity tool in our workflow, not an unreviewed authority. Our security practices are covered in the Security, Privacy & Compliance section.

Yes. We design and build AI chat experiences tailored to the business — from customer-facing assistants to internal tools. A well-designed chatbot is an architecture problem as much as an AI problem, including questions of data access, privacy boundaries, escalation flows, and business integration.

Yes, through retrieval-augmented generation and controlled integrations. The important part is designing clear boundaries around what data the AI can access, how it is retrieved, how it is protected, and what leaves the system. We structure AI integrations so sensitive data is handled according to privacy and security requirements from the start.

It can, but only when the system is architected correctly. We separate what the AI sees from what the AI has access to — for example, a customer-facing AI does not need to hold personal data in its context to escalate a conversation to a human. Correct architecture is what makes AI usable in privacy-sensitive contexts.

Usually not — the highest-value AI projects augment existing operations rather than replace them. AI works best when it removes repetitive work, surfaces information faster, and supports human decision-making. Replacement-focused AI projects often underperform replacement-focused automation of any kind.

Yes, when there is a clear commercial reason to do so. Many projects are better served by commercial APIs with good prompt and retrieval design; some are better served by fine-tuned or fully custom models. We make that decision based on accuracy requirements, cost, data sensitivity, and long-term ownership — not because custom models sound more impressive.

AI systems make mistakes. Production systems are designed around that fact — with retrieval-grounded responses, confidence thresholds, human-in-the-loop checkpoints where it matters, logging, and evaluation pipelines. The difference between a reliable AI product and an unreliable one is almost always the surrounding engineering.

With defined evaluation criteria before the project ships and ongoing measurement afterward — accuracy metrics, task completion rates, user outcomes, and cost per interaction. We do not consider an AI feature delivered just because it generates plausible output; it has to perform measurably on the task it was built for.

Yes. Adding AI to an existing product is one of our common engagement types. We start with an honest assessment of where AI adds commercial value, what data and infrastructure changes it requires, and what the fastest path to a measurable result looks like — before writing any code.

A production AI feature typically includes database and data pipeline work, API design, authentication and authorization, logging and observability, evaluation infrastructure, cost controls, user interface, and integration with existing systems. The AI component is often the smallest part of the overall build — which is exactly why engineering fundamentals matter.

AI costs are engineered, not just monitored. We design for cost efficiency from the beginning — model selection per task, context window management, caching, retrieval instead of bulk context loading, and batching where applicable. Poorly architected AI systems can cost many times more than well-designed ones for the same output.

No. When we use commercial AI APIs in our delivery work, we use configurations that do not send client data to model providers for training purposes. For any custom training involving your data, that only happens with explicit scope and contractual terms in place.

Yes. We build native and cross-platform mobile applications for iOS and Android, covering design, development, testing, app store submission, and post-launch support as an integrated delivery.

Both. The right choice depends on the product — performance requirements, platform-specific features, budget, and long-term maintenance. We recommend a technology direction based on the project, not on which framework we happen to prefer.

We work across the modern mobile stack — Swift for iOS, Kotlin for Android, and cross-platform frameworks including React Native and Flutter. Selection is driven by project requirements, not a one-size-fits-all policy.

For a first submission, plan for approximately two weeks from upload to approval. The first review typically comes back with feedback that needs to be addressed before approval is granted, and that cycle takes time. Subsequent updates are usually much faster — often approved the same day they are submitted.

Apple reviews first submissions in detail, and the review team frequently returns feedback on metadata, privacy disclosures, permission handling, edge cases, or user flow specifics. This is normal. We plan for this feedback cycle from the start rather than being surprised by it, which is why we recommend a two-week window for the first submission.

Apple has raised the quality bar for apps and applies additional scrutiny to apps that appear to be generated without engineering oversight. We build apps to Apple's and Google's quality standards regardless of what tools are used in development — and all code is reviewed, tested, and production-hardened before submission. Our track record is built on apps that meet the guidelines.

By building to the platform guidelines from day one rather than trying to fix compliance issues at the end. That includes correct privacy disclosures, proper permission handling, accessible design, stable performance, appropriate metadata, and adherence to Apple's Human Interface Guidelines and Google's Material Design principles where relevant.

Yes. App store submission — Apple App Store and Google Play — is part of our standard delivery. This includes preparing store listings, screenshots, metadata, privacy disclosures, and managing the review process through to approval.

Yes. Your company should own the developer accounts for both Apple and Google. We will guide you through the setup, but ownership stays with you. This protects your long-term control over your app and its commercial presence.

Yes. We take over existing iOS and Android apps for ongoing maintenance, feature development, and platform update compliance. We begin with a technical audit of the codebase and current deployment setup before committing to scope.

We test across real devices and emulators for functional behavior, performance, edge cases, and platform-specific issues. Testing includes flow testing, crash reporting, network condition testing, and device-specific verification on both iOS and Android.

Usually yes, unless the target audience is clearly concentrated on one platform. We help clients make that decision based on their actual user base rather than a default assumption.

App updates are part of ongoing support agreements. This includes platform update compatibility (new iOS and Android versions), new features, bug fixes, and performance improvements. Apps that are not actively maintained will eventually break as platforms evolve.

Only with active maintenance. Every year Apple and Google release new OS versions that change APIs, deprecate functionality, and tighten privacy rules. We build apps to current standards and maintain them through platform changes as part of ongoing support.

Yes, where they are the right fit. PWAs are commercially attractive for some use cases — faster to ship, no app store dependency, easier to update — but they have real limitations compared to native apps. We recommend the right approach based on what the product actually needs.

Yes. Most apps we build include backend integration — authentication, data synchronization, payments, notifications, analytics, and third-party APIs. Mobile and backend are typically delivered as one engagement.

Most projects begin with a short discovery conversation to understand what you are trying to achieve. From there, we move into a requirements specification — either working from one you already have, or helping you build one. A clear specification is the foundation of a successful project, so we invest real effort at this stage before writing any code.

Discovery, requirements specification, proposal and contract, design, development in structured phases, testing and quality assurance, deployment, and handover. Support and maintenance continue afterward if agreed. We keep this process deliberately structured because ambiguity at any stage creates cost and delay.

No. If you have one, we work from it. If not, we help you build one. You can start by clicking **Start new project** on our website — you will chat with us directly, and we will put together a specification that becomes the basis for an accurate proposal. Many clients start at exactly this point.

The clearer the specification, the better the project. Ambiguity that enters at the start gets amplified later — leading to last-minute changes, scope disputes, additional cost, and project delays. Time invested in a thorough specification upfront consistently produces a better outcome than trying to figure things out as you go.

Changes are normal and we accommodate them, but we handle them through a clear change process rather than informal adjustments. This protects both sides — you see the cost and timeline impact before agreeing, and we avoid ambiguity about what was agreed versus what was added. Well-scoped projects at the start minimize the need for changes later.

It depends entirely on scope — small integrations can be delivered in a few weeks, full custom platforms run for several months, and long-term engagements continue as ongoing partnerships. We give a realistic timeline in every proposal based on the actual work, not a marketing number.

Email for written communication and documentation, and video meetings for discussion and working sessions — we use Google Meet, Zoom, or similar platforms depending on client preference. We adapt to the communication tools your organization already uses rather than forcing ours on you.

Meeting cadence is matched to the project — typically a weekly review for active development phases, with additional sessions during discovery and launch. Between meetings, communication continues asynchronously by email or chat.

You will have a clear primary point of contact throughout the project — not a shifting cast of account managers. Depending on the engagement, you may also work directly with designers, developers, and QA engineers involved in your build.

Our operations are well-aligned with European business hours. For clients in North America, we routinely structure workflows so a daily sync during US morning hours is possible when the engagement requires it. For Asia-Pacific clients, our Bangkok base provides strong time zone overlap.

We run projects with structured milestones, documented requirements, and regular status communication. We adapt to the project management tools your organization uses — or provide our own — and we keep the overhead proportional to the project size.

Delivery includes deployment to your production environment, documentation of the system, handover of source code and credentials, and a walkthrough with your team. When a project goes live and is in active use, it is considered accepted and delivered.

When the delivery is live and in use, the project is automatically considered accepted. We do not build in drawn-out acceptance phases that delay final sign-off after a product is already running in production.

Yes. Training and documentation are part of handover for any project where your team will be operating the system. This is sized to the project — from a short walkthrough for simple tools to structured training sessions for larger platforms.

Projects can be paused by agreement, and commercial terms for pause and resumption are defined in the contract. Stopping a project mid-delivery is always possible, with commercial terms based on work completed to date. We do not lock clients into engagements they no longer want.

We address it directly. In practice, structured discovery and a clear specification prevent most quality disputes before they happen. If something is not meeting expectations during delivery, we want to know as early as possible so we can adjust — not at the end of the project.

Yes. We sign NDAs as standard practice, either on our template or yours. NDA coverage is in place before any sensitive project details are discussed in depth.

Every project is tailored to the client, so we do not publish fixed prices. We build an accurate proposal based on your specific requirements — which is why the requirements specification stage matters. Once we understand the scope, a proposal can usually be put together quickly.

Because meaningful prices depend on scope, complexity, integrations, design work, and support requirements. Any number we publish without understanding your project would either be misleading or meaningless. We prefer to give you a real number based on real scope.

We work with fixed-price contracts for well-defined projects, variable-rate engagements for exploratory or evolving work, and fixed-price support agreements for ongoing maintenance and retainer relationships. The right model depends on the project — we recommend what fits, rather than defaulting to one structure.

Fixed pricing works best when the scope is well-defined — typically after a thorough requirements specification. It gives both sides commercial certainty and is usually the preferred model for new projects with clear deliverables.

Variable pricing fits engagements where scope is expected to evolve — ongoing development, experimentation, research-driven work, or partnerships where the direction will adapt based on results. It gives flexibility without forcing artificial scope boundaries.

Yes. Support and maintenance agreements are typically structured as fixed monthly pricing based on defined scope — response times, monthly hours, coverage, and priority handling. This gives you predictable costs and gives us predictable capacity allocation.

For most projects, payment is structured as 50% at project booking and 50% before delivery — meaning before the work goes live. For longer or larger projects, we structure payments around milestones rather than a single split. The specific terms are agreed in the contract for each engagement.

Because the final payment is due on a completed, tested, deliverable project — not after it has been in production use. This is a standard commercial structure for development work and protects both sides: you only pay on a finished product, and we release a finished product on agreed terms.

Yes. For larger projects, we structure payments around defined milestones — typically tied to phase completion, design approval, development stages, and launch readiness. This keeps commercial flow aligned with delivery progress.

We accept bank transfer and card payment. Specific payment instructions are provided with each invoice.

VAT only applies to clients based in Thailand, where it is legally required. For clients outside Thailand, no VAT is charged.

Scope, complexity of integrations, design requirements, security and compliance needs, testing depth, ongoing support, and timeline. A faster delivery against a fixed deadline may also affect pricing. We explain the drivers in every proposal so you understand what you are paying for.

Long-term engagements and retainers are typically structured at rates that reflect the committed capacity. We do not use discount headlines as a sales tool — pricing reflects the work and the relationship.

Yes. An initial discovery conversation is free — it helps us both understand whether there is a fit before anyone invests further time. Detailed specification work beyond discovery is a scoped engagement.

Scope changes are handled through a change process rather than absorbed quietly. If something new is requested mid-project, we estimate the cost and timeline impact, you approve or adjust, and the change is added to the agreement. This protects both sides.

We can provide ballpark ranges during discovery based on comparable projects, but we do not issue formal proposals without enough detail to be accurate. Issuing numbers without a proper scope serves no one.

We take on small, well-scoped projects as well as larger engagements. What matters is that the work is defined clearly enough to deliver well — not the price tag.

We are language-agnostic and work across the modern development stack. Our team routinely delivers in JavaScript and TypeScript, Python, PHP, Ruby, Swift, Kotlin, Java, C#, Go, and others. With AI-assisted engineering and 30 years of foundational experience, we select the right technology for each project rather than forcing projects into a preferred stack.

We work with modern web frameworks including React, Next.js, Vue, Angular, Node.js, Laravel, Django, Ruby on Rails, and others. Framework selection depends on the project — performance needs, ecosystem fit, long-term maintenance, and integration requirements.

Relational databases including PostgreSQL, MySQL, MariaDB, and Microsoft SQL Server; NoSQL databases including MongoDB, Redis, and DynamoDB; and specialized stores including vector databases for AI applications. Database choice is a foundational architectural decision and we treat it that way.

AWS, Google Cloud, and Microsoft Azure are our primary cloud platforms. We deploy, configure, and operate production infrastructure across all three depending on client preference and project fit.

Yes. Automated testing, continuous integration, and automated deployment pipelines are standard practice on our projects. This is not optional infrastructure — it is how modern software is built and maintained reliably.

Scalability is designed in from the beginning, not retrofitted. For every project we consider expected load, database scaling, caching strategy, background job processing, and stateless service design. We build for the scale the project realistically needs, not speculative scale that adds cost without benefit.

Performance is a first-class concern — front-end performance, database query optimization, API response times, and infrastructure-level tuning. Performance issues found in production are far more expensive than performance designed in from the start.

Yes, where it makes sense. API-first architecture gives clients the flexibility to extend their systems, integrate new channels, and build additional products on top of the foundation. We recommend it when long-term extensibility matters.

Yes. System integration is one of our most common engagement types — CRMs, ERPs, payment processors, accounting systems, analytics platforms, and custom APIs. We work with modern REST, GraphQL, gRPC, and legacy SOAP or file-based integrations where required.

Yes. Taking over existing code is a routine engagement. We start with a technical audit to understand code quality, architecture, dependencies, and technical debt — then give an honest assessment of what should be preserved, refactored, or replaced.

Code quality is enforced through code review, automated testing, linting, type checking, and architectural review on every project. We do not rely on any single mechanism — quality is a layered practice.

Yes. We build to WCAG standards as part of our design and development process, with accessibility considered from the start rather than retrofitted. For projects with specific compliance requirements, we work to the required WCAG level.

Yes. Every web project we build is responsive and designed to work across device sizes. Mobile-first approaches are standard where the audience is primarily mobile.

We build for modern browsers as standard (latest versions of Chrome, Safari, Firefox, Edge). Legacy browser support — including older versions of Internet Explorer or niche requirements — is handled case by case when there is a real business need, with the trade-offs explained.

Yes. Code is documented to professional standards, and system-level documentation is delivered as part of project handover. Documentation depth is sized to the project — enough that another competent engineer could pick up the system without tribal knowledge.

Yes. Source code ownership is covered in the IP, Contracts & Ownership section, but the short answer is: clients receive full source code for the work they commission.

Yes — AI-assisted development is part of how modern engineering teams work efficiently. All AI-assisted code passes through the same review, testing, and architectural oversight as any other code. The productivity gain comes from experienced engineers using AI well, not from AI replacing engineering judgment.

Technical debt is tracked and addressed deliberately rather than ignored until it becomes a crisis. In new projects, we design to minimize it; in existing codebases we take over, we assess it upfront and propose a realistic remediation path.

Security is designed in from the start, not audited in at the end. Every project includes secure architecture, authentication and authorization design, input validation, dependency management, secrets handling, and security testing as part of standard delivery — not as an optional add-on.

Yes. We offer security audits as a standalone service and as part of development engagements. Our audit coverage includes OWASP Top 10 vulnerabilities, dependency and library scanning, secret scanning, container and infrastructure scanning, and network-level assessment.

We build to OWASP guidelines as a baseline, and to specific standards where projects require them — including industry-specific compliance needs. For projects with regulatory requirements, we align the security approach with the applicable framework.

Yes. For clients serving European users, we build systems that comply with the General Data Protection Regulation — including lawful basis for data processing, data minimization, user rights handling, breach procedures, and data processing agreements where required.

Yes. Since we operate from Thailand, we work regularly with the Personal Data Protection Act (PDPA) — Thailand's data protection framework. PDPA shares many principles with GDPR but has its own specific requirements, and we handle both where projects span jurisdictions.

Client data is handled under NDA, with access limited to the team members working on the engagement. Credentials are managed through secure systems — never shared in email or chat — and production access follows least-privilege principles.

Development data is stored in secure, access-controlled environments appropriate to the project. Production data storage is determined by the project's own architectural and compliance requirements — typically in the client's chosen cloud region.

Yes, as standard practice before any sensitive project detail is discussed. We sign on our template or yours.

Yes. For projects where we act as a data processor under GDPR, PDPA, or equivalent frameworks, we sign Data Processing Agreements that define the scope and obligations of data handling.

We implement modern authentication patterns — OAuth, SSO, multi-factor authentication, session management, and role-based access control — sized to the project's actual security requirements. Authentication is an area where shortcuts are especially costly, so we get it right from the start.

Yes. Secrets are managed through dedicated secret management systems — never checked into source code, never shared in plain text. We scan for leaked secrets as part of our delivery process.

Security issues discovered after launch are handled as a priority. For clients on support agreements, this is part of standard coverage. For clients without active support, we respond on a case-by-case basis and recommend putting a support structure in place.

Yes. Dependency scanning is part of our standard development and maintenance practice — catching known vulnerabilities in libraries and frameworks before they reach production, and alerting on new vulnerabilities in deployed systems.

With deliberate architectural boundaries. AI systems are designed so sensitive user data is not placed in AI context unnecessarily, AI providers are configured to not retain data for training, and data flows are documented and controlled. This is covered in more detail in the AI & Modern Development section.

Yes. Penetration testing is offered as part of security-focused engagements. For high-stakes systems, we also work alongside specialist penetration testing firms where clients require third-party verification.

Through ongoing support agreements that include dependency updates, platform patches, monitoring, and timely response to new vulnerabilities. Systems that are not actively maintained become insecure over time as the threat landscape evolves.

You do. On standard engagements, intellectual property rights to the work we build transfer to the client upon final payment. You commission the work, you own the output.

Yes. Full source code is delivered at project handover, along with documentation and deployment details. There are no hidden components or rental-based code arrangements in our standard engagements.

Open-source components remain under their original licenses — we do not sublicense them. Our work integrates and uses open-source libraries in accordance with their terms, and we document which components and licenses are in use.

We do not reuse client-specific code across other client projects. We do maintain internal tooling, general libraries, and knowledge that carries across projects — this is standard engineering practice and does not include client-specific business logic or proprietary code.

This is defined in the contract. In standard engagements, rights transfer on payment — so work that has been paid for belongs to you, and the commercial terms for parting mid-project are clearly defined before the engagement begins.

Yes. Every engagement is covered by a written contract that defines scope, deliverables, timeline, payment terms, IP, confidentiality, and termination terms. We do not work on handshake commitments for anything beyond initial discovery.

Yes. We often sign on the client's contract template where the terms are reasonable. For clients who prefer, we provide our standard contract as a starting point.

Yes, as standard practice. NDAs are in place before any sensitive project detail is discussed in depth.

Through NDAs, internal access controls, and delivery practices that limit sensitive information to the team members working on the engagement. Confidentiality obligations continue after project completion.

Your customers' data belongs to your business, not to us. We do not claim rights over data processed by systems we build, and our engagement terms make this explicit.

Source code, documentation, credentials, and deployment details are delivered at handover — which means another developer can take over your system without needing us. We do not structure projects to create dependency on our continued involvement.

No. The pricing agreed in the contract is the pricing. Any third-party services with their own licensing (cloud hosting, payment processors, AI APIs) are clearly disclosed, and those licenses are between you and the provider — not bundled or marked up through us.

We carry appropriate professional arrangements for the work we deliver. Specific insurance requirements are discussed per engagement where clients require formal coverage terms.

Our contracts include dispute resolution terms — typically starting with direct negotiation, then structured escalation if required. In practice, clear specifications, transparent change processes, and regular communication prevent most disputes from arising.

Yes. We regularly work with corporate procurement requirements — including vendor onboarding, compliance documentation, and structured contracting processes — and we provide the documentation and information typically needed.

Over our history, we have delivered projects across a wide range of industries — from real estate and financial services to hospitality, professional services, skilled trades, and consumer products. The common thread is not industry, but clients who treat technology as a strategic investment.

We have particular depth in dating, delivery, e-commerce, security, real estate, and photography. These are sectors where our team has not only delivered client work but has also built and operated our own products and businesses — giving us operator-side perspective that shapes how we approach client projects in these areas.

Yes. We have delivered real estate platforms, property management tools, listing systems, lead intelligence platforms, and AI-driven real estate applications. Real estate is one of our areas of operator-side experience.

Yes. We build e-commerce platforms ranging from custom storefronts to platform-based implementations, integrated with payment providers, inventory and fulfillment systems, and analytics. E-commerce is one of our areas of deepest industry experience.

Yes. We have built dating platforms and social applications — including user matching systems, messaging infrastructure, moderation tooling, and monetization flows. This is an area where we have operated our own products.

Yes. We have delivered platforms in the delivery and logistics space — including order management, driver applications, routing, and customer-facing tracking. This is another area of operator-side experience.

Yes. We work with photography platforms, media processing systems, and AI-assisted photo enhancement. Our team has built and operated products in this space.

Yes. Security is both a practice area (see the Security, Privacy & Compliance section) and an industry we have delivered into — including security-focused platforms and tooling.

Yes, with appropriate scope. We have delivered projects in the financial services space including pension platforms and financial tooling. Regulatory considerations are addressed as part of scope.

Yes. We have delivered projects in hospitality including booking systems, guest-facing platforms, and operational tools.

Yes. Professional services — including law firms, veterinary practices, accounting firms, and similar — are often underdigitized and benefit significantly from well-executed technology. We have delivered projects across these sectors.

Yes. Skilled trades businesses often operate with outdated or disconnected systems, and the commercial impact of good software in these businesses is significant. We have delivered projects across skilled trade sectors.

Yes, with appropriate scope and regulatory awareness. Healthcare projects require careful handling of privacy, compliance, and clinical workflow — we address these as part of scope.

Yes. We have delivered educational platforms and e-learning tools. Scope is defined per project.

Yes. We work with startups that have validated their concept and have funding or revenue to sustain an engagement. We do not take on speculative pre-funding builds or equity-only arrangements.

Most of our engagements are not limited by industry — they are shaped by the nature of the problem and the quality of the opportunity. If your project requires thoughtful software engineering, there is a strong chance we are a fit regardless of sector. A short discovery call will confirm it quickly.

Yes. Post-launch support is available through structured support agreements with defined response times, monthly scope, and priority handling. Most clients transition into an ongoing relationship after the initial delivery rather than treating launch as the end of the engagement.

Software is not a one-time delivery — platforms evolve, operating systems update, libraries reveal vulnerabilities, browsers change, and business needs shift. Systems without active maintenance degrade over time, become insecure, and eventually break. Ongoing support keeps what you have paid for working reliably.

Typical support agreements cover bug fixes, security updates, dependency management, platform compatibility updates (iOS, Android, browsers), minor feature improvements, performance monitoring, and priority response for issues. Specific scope is defined per agreement.

Support agreements are priced at fixed monthly rates based on defined scope — response times, monthly capacity, coverage hours, and priority levels. Fixed pricing gives you predictable costs and gives us predictable capacity allocation.

Response times depend on the support tier and the severity of the issue. Critical production issues are prioritized on a faster response than routine requests. Specific response times are defined in each support agreement.

Extended coverage hours are available for clients with production systems that require it. Standard support operates during business hours; 24/7 or extended coverage is scoped and priced per engagement.

We offer ad-hoc support on a case-by-case basis, but clients with active systems typically benefit from structured support agreements — faster response, predictable costs, and reserved capacity. Ad-hoc support is available when it suits the situation.

New OS releases regularly change APIs, deprecate functionality, and tighten rules. Apps under active support are tested against new OS versions and updated to remain compatible and compliant. Apps without active support gradually become incompatible.

Yes. Support agreements can include proactive monitoring — uptime, error rates, performance, and security alerts — so issues are identified and addressed before they become customer-facing problems.

Yes. Taking over support for an existing system is a common engagement. We begin with a technical audit to understand the codebase, infrastructure, and current state — then define a support scope that fits the system realistically.

Small features within the agreed monthly scope are handled as part of the support agreement. Larger features or new initiatives are scoped and proposed separately, keeping support capacity dedicated to maintaining what is already live.

By severity — critical production issues first, then high-impact functional issues, then lower-priority improvements. The prioritization approach is agreed at the start so expectations are clear.

Yes. Support scope is reviewed periodically and adjusted to reflect how the system is actually being used. Systems typically need more support immediately after launch and stabilize into a lower ongoing scope.

Emergency handling outside business hours is part of extended support coverage. Standard support agreements can be upgraded to include emergency coverage for systems where downtime has significant commercial impact.

Support agreements can be ended with agreed notice. On termination, you retain all code, documentation, and credentials — so another provider can take over, or you can bring the work in-house. We do not structure support to create lock-in.