Frequently Asked Questions

Yes — full-stack development covers the user interface, backend APIs, database design, and third-party integrations in one engagement.

Yes, we regularly extend and modernize existing React/Node applications alongside building new ones from scratch.

It depends on your data model — we typically use PostgreSQL for relational data or MongoDB for flexible, document-based needs, and will recommend based on your specific use case.

It depends on feature scope, integrations, and timeline — we scope cost against your specific requirements during discovery rather than quoting a generic range upfront.

Yes, ongoing support and maintenance is available after launch, covering bug fixes, dependency updates, and further feature development.

Yes — we can scope a fixed feature set to fit a defined budget, and flag trade-offs upfront if something doesn't fit within it.

They let us deliver a fast, fully featured Android app in less time, and the same code can become your iOS app later. We pick Flutter or React Native depending on your product and any existing React code your team already has.

Yes. We profile the app on low- and mid-range devices, not just flagships, and tune images, lists, and animations so it stays smooth across screen sizes and Android versions.

Yes. We store data on the device and sync it to Firebase, MongoDB, or PostgreSQL in the background once the connection comes back, so nothing is lost.

We use Firebase Cloud Messaging, Google's own notification service, to send targeted and scheduled notifications to your Android users.

Yes — store listing, data safety form, content rating, and release through internal testing, closed testing, and staged production rollouts.

Yes. Because the app is built in Flutter or React Native, most of the code carries straight over, so an iOS release is a much smaller project than starting from scratch.

We offer maintenance covering new Android versions, Play policy updates, crash monitoring, and bug fixes, plus new features as your users ask for them.

Flutter is great when you want a highly custom, pixel-perfect design; React Native suits teams that already work in React or want to share logic with a web app. We recommend one during discovery based on your product.

In practice, no. Both frameworks compile to real iOS apps, and we follow Apple's Human Interface Guidelines for navigation, gestures, typography, and haptics so it feels at home on iPhone.

Yes. We implement App Store in-app purchases, auto-renewing subscriptions, and Apple Pay, and keep purchase records in Firebase, MongoDB, or PostgreSQL.

We complete the App Store privacy labels, add App Tracking Transparency prompts where needed, and only request the permissions your app genuinely uses — the most common reasons for rejection.

Yes. We ship regular TestFlight builds so you and your beta users can try every feature on real iPhones and iPads before release.

We handle the fix and resubmission, respond to App Review, and work through their feedback until the app is approved.

Yes. The same Flutter or React Native codebase can be released on Google Play with a modest amount of extra work, rather than a second full build.

Most MVPs launch in 4–8 weeks depending on scope, using a fixed-scope build process focused on your core value proposition.

Yes, we architect MVPs on a scalable foundation so the product can grow into a full platform rather than being rebuilt from scratch.

Rapid prototyping, core feature development, and a production-ready deployment you can put in front of real users and investors.

Cost depends on your core feature scope — we help you prioritize the minimum set of features that actually tests your hypothesis, so you're not paying to build things you don't need yet.

Most MVPs move into an iteration phase based on real user feedback — we can continue as your ongoing development team or hand off a well-documented codebase.

We focus on the product itself, but a working, demo-ready MVP is often the strongest asset for investor conversations, and we build with that audience in mind.

Yes, we integrate Stripe (or another provider of your choice) for subscription management, invoicing, and usage-based billing.

Multi-tenancy lets one codebase and database securely serve many customer organizations. It's standard for most SaaS products, and we design it in from the start.

Yes, white-label theming and partner-specific configuration is something we've built into SaaS platforms before.

It depends heavily on scope — a single-tenant MVP with basic billing costs far less than a multi-tenant platform with usage-based pricing and enterprise SSO. We scope cost against your specific feature set during discovery.

Yes — flat-rate, usage-based, and tiered pricing each affect the technical architecture (metering, invoicing logic) differently, so we typically discuss this early in discovery alongside the product roadmap.

Yes, usage dashboards and churn-relevant metrics are part of most SaaS engagements, since they're core to understanding retention.

A PWA runs in the browser but can be installed to the home screen, work offline, and send push notifications — without an app store listing.

Yes, offline functionality via service workers is a core part of every PWA we build.

Yes, users can add it to their home screen, and it behaves like a native app icon and launch experience.

A PWA doesn't list in app stores by default, though wrapped PWAs can be submitted to some stores. If store presence is a hard requirement from day one, we'll factor that into the platform recommendation.

No — PWAs are still crawlable, server-renderable web pages, and the performance gains from service workers typically help SEO rather than hurt it.

Yes, adding a service worker, manifest, and offline support to an existing site is a common upgrade path rather than a full rebuild.

Both — we choose based on your requirements around cost, data privacy, and performance.

Yes, most AI application work we do integrates into an existing product rather than requiring a full rebuild.

We design the integration around your data governance requirements, including options to keep sensitive data within your own infrastructure.

It varies by complexity — a chatbot grounded in existing documentation is a smaller engagement than a custom fine-tuned model or multi-step agent system. We scope based on your specific use case.

Yes — part of our discovery process is assessing whether an AI approach actually solves the problem better than simpler automation or rules-based logic.

We architect around provider rate limits and cost controls from the start, including caching, fallback models, and usage monitoring, so costs stay predictable as usage grows.

Yes, we typically plan phased migrations that keep the existing system running while the new one is built and validated.

Yes, ERP and enterprise system integrations, including SAP and Oracle, are part of our enterprise engagement work.

We build in security compliance and high-availability architecture from the design phase, tailored to your industry's requirements.

Enterprise projects typically involve multiple stakeholders with different priorities — we run structured discovery sessions to surface requirements and conflicts early, before development starts.

Yes, we can work within standard enterprise procurement processes, including NDAs, MSAs, and vendor security questionnaires.

It depends heavily on system complexity and integration scope — enterprise engagements typically run longer and involve more stakeholders than a standalone product build, so we scope budget after a discovery phase.

Both — our process includes user research, wireframing, and usability testing, not just visual design.

All product design happens in Figma. We use Figma Make to turn designs into interactive prototypes, AppLaunchpad for App Store and Google Play screenshots, and Canva for marketing and social graphics.

Yes. We build interactive prototypes with Figma Make so you and your users can try the real flows on desktop or phone and give feedback before any code is written.

Yes. We create store screenshots and preview images in AppLaunchpad, sized correctly for every device the stores require, so your listing is ready on launch day.

We can do both — design work is often paired with our development services, or delivered standalone with developer-ready handoff.

It depends on your needs — a single product launch might just need page designs, while a growing multi-product company benefits from a reusable design system.

Yes, redesigns are often scoped incrementally — flows and screens with the biggest usability impact first, without requiring a ground-up rebuild.

Yes, usability testing on prototypes is part of our process when the budget and timeline allow, so issues get caught before engineering time is spent.

We work across Azure and GCP, and will recommend based on your existing stack and requirements.

Yes, adding CI/CD pipelines to an existing project is one of our most common DevOps engagements.

Yes, cost optimization is part of our infrastructure review, alongside monitoring, logging, and security automation.

Yes, we typically start with an infrastructure review to understand what's already in place before proposing changes, rather than rebuilding from scratch.

Both — we can hand off a documented setup for your team to manage, or stay on for ongoing infrastructure management and monitoring.

We set up monitoring and alerting so issues are caught early, and can define an on-call or incident-response process depending on your support needs.

Yes, containerizing an existing app without rewriting it is one of our most common engagements in this area.

Often minimal — most applications can be containerized with configuration changes alone, though we'll flag anything that genuinely needs code-level changes upfront.

Yes. A Docker Compose setup lets any developer start the full app — frontend, API, and database — with a single command.

We use small, official base images, run containers as non-root users, keep secrets out of images, and scan images for known vulnerabilities before release.

Usually unneeded build tools and poor layer ordering. We use multi-stage builds and layer caching to cut image size and build time significantly.

Yes, we set up your CI/CD pipeline to build, test, and tag Docker images automatically on every change, so every release ships the exact image that was tested.

It depends on how standard your sales process is — we can customize platforms like Salesforce and HubSpot, or build a bespoke CRM when your workflow needs something they don't support well.

Yes, integrating with marketing, support, and billing tools is a core part of most CRM engagements.

Yes, mobile CRM access is something we build in when field or remote sales teams need it.

Yes, data migration from spreadsheets or a previous CRM is a standard part of most CRM engagements.

Yes, we typically include onboarding and training so your team is comfortable with the new system from day one.

Yes, connecting the CRM to your marketing, support, and billing stack is a core part of most engagements, not an afterthought.

Off-the-shelf software is built for the average user across many companies. Custom software is designed specifically around your workflows, data, and integrations, so it fits without requiring you to change how you operate.

Both — custom software development at DotLinker covers web applications, mobile apps, and the APIs and integrations that connect them, chosen based on how your team and customers will actually use the system.

We regularly build custom software that integrates with or replaces parts of an existing stack, rather than requiring a full rebuild from scratch.

You get a working team immediately, without the time and cost of hiring, without the overhead of employment when the project scope changes, and with our existing delivery process already in place.

Yes — you own the code we build for you as part of the engagement, so there's no vendor lock-in once the project is delivered.

Yes, we regularly work as an extension of an existing team rather than replacing it, coordinating through your existing tools and processes.

Both — from marketing websites to full web application platforms — and we'll recommend the right approach based on what the site actually needs to do.

Yes, SEO-friendly architecture, fast load times, and proper metadata are built in from the start, not added as an afterthought.

Yes, migrating from WordPress, Wix, Squarespace, or similar platforms to a custom-built site is a common engagement for us.

A marketing website typically takes 4–10 weeks; a full web application takes longer depending on feature scope — we'll give you a specific timeline after understanding your requirements.

Yes, we can set up hosting and domain configuration as part of the launch process.

Yes, multilingual content and region-specific routing are things we've built into web development engagements before.

It depends on your budget, timeline, and how much platform-specific functionality you need — we'll walk through the trade-offs and recommend native (Swift/Kotlin) or cross-platform (Flutter) based on your specific requirements.

Yes, simultaneous iOS and Android development is one of our most common engagements, whether built natively per platform or with a shared cross-platform codebase.

Yes, we manage App Store and Google Play submission, listing setup, and compliance requirements through to approval.

Cost depends on platform scope (one platform vs. both), feature complexity, and whether you need native or cross-platform development. We provide a scoped estimate after understanding your requirements.

Yes — OS updates, device compatibility, and bug fixes are ongoing needs for any published app, and we offer maintenance packages for post-launch support.

Yes, we regularly take over existing codebases — we start with a code and architecture review before making changes, so you understand what you're inheriting.