The questions that come up in every first call

A focused marketing or consultation site is typically two to four weeks of work. A full web application with authentication, a database and an admin surface is usually six to twelve weeks. A first mobile release is eight to fourteen weeks. Exact pricing comes after discovery, because quoting before understanding the scope produces a number that is wrong in one direction or the other.

Fixed-scope projects are fixed-price, quoted after discovery against a scope you have signed off. Ongoing work runs as a monthly retainer with a reserved number of days. Joining an existing team runs on a day rate. Hourly billing on an undefined scope serves neither of us.

It gets quoted as a change, in writing, before it is built. What does not happen is silent absorption — which ends in a rushed delivery — or silent omission, which ends in a launch missing something you assumed was included.

Yes, as a monthly retainer covering dependency and security patching, platform compatibility work, monitoring and a budgeted allowance for small changes. Declining a retainer is a legitimate choice — you just get a documented pipeline your own team can run, and you make that decision knowingly.

Fixed-scope projects are invoiced in stages tied to delivery — typically a deposit to start, one or more payments at agreed milestones, and a balance at handover. Retainers are invoiced monthly in advance. Nothing is billed for work that has not been done.

No, and deliberately so. Hosting, domains and third-party licences stay in your name and on your card, because software you cannot pay the bills for is software you do not really own. Typical running costs are estimated during discovery so the total is not a surprise, and the platforms used here mostly have generous free tiers.

Usually within one to three weeks, depending on what is already committed. Discovery can often start sooner than the build, which is useful — it means the scope is ready the moment capacity opens up rather than starting from scratch then.

A focused marketing or consultation site is typically two to four weeks from discovery to launch. A content-managed site with multiple templates is four to six. A full web application with authentication, a database and an admin surface is six to twelve weeks, delivered in working increments rather than as one launch date.

Sometimes, and the honest answer comes in discovery rather than after you have paid. If the deadline is real — a funding round, a launch event, a regulatory date — we scope backwards from it and decide together what ships and what waits. A deadline met by quietly dropping the security review is not a deadline met.

From the first week. There is a deployed preview URL you can open on your own phone, updated continuously, rather than a demo at a milestone meeting. The MVP stage exists specifically so you are using a real thing while changing direction is still cheap.

Waiting on decisions and waiting on content, in that order — almost never the code. The stages in the process each name what is needed from you for exactly this reason. A business rule that takes two days to get answered is two days added to the timeline, and it is worth knowing that before it happens rather than after.

Web on React/Next.js, Vue/Nuxt or Astro; backends on Node/NestJS, Python/Django or FastAPI, Go, or PHP 8.2+; mobile on Swift and SwiftUI for iOS, Kotlin for Android, or React Native and Flutter for cross-platform. The stack is chosen per project against your constraints — not every project uses every one of these.

Because the right answer differs. An ashram that cannot carry a maintenance contract got 21 KB of static HTML on Bootstrap that will still work in a decade. A publisher whose editors will not leave WordPress got engineering work done around WordPress. Regional news editions that need stories crawlable immediately got server-rendered Next.js. Picking one stack for every client is a preference, not an engineering decision.

Usually, yes — and usually the cause is rendering strategy, unbounded third-party scripts, or images shipped at the wrong size, in that order. A one-week audit gives you before-and-after Lighthouse numbers, a rendering audit showing what crawlers actually see, and a prioritised fix list with effort estimates.

Yes — as a design system rather than a set of pictures: tokens, type scale, spacing, and every component designed with its loading, empty and error states, since those are most of what users actually see. Accessibility is checked at design time, not retrofitted after.

Yes — either on a hosted platform when you want to run it yourself with no engineering on call, or custom when the catalogue, pricing rules or checkout genuinely do not fit an off-the-shelf platform. That choice gets made in discovery, and the honest recommendation is often the hosted one.

Yes — Razorpay, Stripe, PayPal and similar. Payment work is done server-side with webhook verification and idempotency handling, because the failure mode that matters is not a broken checkout, it is a customer charged twice or an order that never records.

Yes, if that is a requirement — say so in discovery, because it changes the build. Options run from a headless CMS to a simple admin surface to plain markdown files, and the right one depends on who is editing and how often. If nobody will actually edit it, a CMS is cost with no return.

Yes. Four sites in this portfolio serve Hindi content, three of them as server-rendered Devanagari with the correct language declaration and structured data so search engines index them properly. Multi-language support is a build-time decision rather than a plugin, so raise it in discovery.

If the app is mostly forms, lists and API calls, React Native or Flutter gets you two platforms for close to the price of one and your users will not notice the difference. If it leans on the camera, background location, widgets, HealthKit or heavy animation, native Swift and Kotlin costs less in total than fighting a bridge. That decision is made in discovery, with the tradeoff written down.

More, generally — a first app release is typically eight to fourteen weeks against two to four for a focused site, because there are two platforms, store review, and an API to design alongside. Cross-platform narrows that gap considerably when the app is mostly forms, lists and API calls. Exact pricing follows discovery.

Most businesses asking for an app need a fast mobile website. An app earns its cost when you need push notifications people actually act on, offline use, camera or background location, or when repeat usage is high enough that an icon on the home screen changes behaviour. If none of those apply, a website reaches everyone immediately with no store review and no install friction.

Usually 24 to 48 hours once the submission is correct — the delay is almost always a rejection, not the queue. Privacy labels, account deletion, sign-in requirements and permission strings that do not explain themselves are the predictable causes, and they are handled before the first submission rather than after.

Under a retainer, yes — and mobile is the clearest case for one. iOS and Android both ship releases every year that deprecate APIs, change permission behaviour or tighten store policy. An app nobody maintains does not stay working; it stays working until the next OS release.

It answers from a knowledge base of documents about the services, the case studies, the process and the pricing models on this site. Ask it something outside that and it will tell you it does not have the information and offer to connect you on WhatsApp, rather than guessing.

A retrieval-grounded assistant answers only from documents you control and refuses when nothing relevant is retrieved. That reduces fabrication substantially and turns the failure mode into a visible refusal rather than a confident invention. It is not an absolute guarantee, and I will not sell it as one — which is exactly why the evaluation harness includes questions that must be refused, run on every deploy.

Per-request token cost and latency are instrumented from the first build, so you see the running cost before launch rather than in your first invoice. Retrieval quality and caching are the two levers that actually move it — a well-built retrieval layer sends far fewer tokens to the model.

Whichever fits the constraint — cost, latency, data residency, quality. The retrieval layer and the generation layer are kept separate, so the model stays a swappable dependency rather than an architectural commitment you are locked into.

In order of how often it turns out to be the cause: rendering strategy, unbounded third-party scripts, and images shipped at the wrong size. A one-week audit gives you before-and-after Lighthouse numbers, a rendering audit showing what crawlers actually see per template, and a prioritised fix list with effort estimates against each item.

It can, and that risk is managed rather than hoped away. URL structure is preserved wherever possible, every changed URL gets a 301 redirect, structured data and metadata are carried across, and the sitemap is resubmitted at launch. Rankings usually wobble for a week or two after any migration; without redirect discipline, they do not come back.

Technical fixes — rendering, structured data, Core Web Vitals — show up in weeks because they change how quickly and reliably you get crawled. Ranking for competitive terms is a content and authority problem measured in months, and no amount of engineering substitutes for it. Anyone promising a timeline for rankings is guessing.

I write the structural copy that carries SEO weight — page titles, headings, service descriptions, FAQ answers — and the technical content. Ongoing editorial content is usually better produced by someone inside your business who knows the subject; I set up the structure and the internal linking so that content actually gets found.

Yes — GA4 through Tag Manager, or a lighter privacy-respecting option like Plausible or Vercel Analytics where you do not need the full stack. Measurement goes in before launch rather than after, because a launch you cannot measure is a launch you cannot learn from. No invasive tracking, and no third-party sharing you have not agreed to.

You do, from the first commit. Work happens in your repository or is transferred to your organisation at handover, with full history, environment documentation and a local setup a new developer can run in under fifteen minutes.

Server-side input validation on every route that accepts input, CSRF protection and rate limiting on mutating endpoints, security headers including CSP and HSTS, no secrets in the client bundle, and dependency scanning in CI that fails the build on high and critical findings. These are part of the build, not a paid extra.

SSL is automatic on the platforms used here and is handled as part of deployment. Domain registration and ICANN registrant verification require your legal identity and payment, so they stay in your name — with guidance through the process. SOC 2 and ISO 27001 require an accredited independent auditor; I implement and document the technical controls and prepare the evidence, but the audit itself cannot be automated by anyone, and I will not imply otherwise.

The technical controls are implemented — minimal data collection, no third-party sharing you have not agreed to, cookie and consent handling where analytics require it, and a documented record of what is collected and why. The policy text itself and the legal determination for your jurisdiction should come from a lawyer, not a developer, and I will tell you that rather than hand you a template and imply it is advice.

Nothing, and that is the point of doing handover properly. The repository is in your organisation with full history, the README gets a new developer running locally in under fifteen minutes, architecture decisions are documented, and every credential is in your accounts rather than mine. If your business depends on being able to reach me, the handoff was done badly.

Defects — anything that does not do what the agreed scope said it would — are fixed at no charge for 30 days after launch. New features and changes of mind are quoted as changes. The distinction is deliberate and is written into the proposal so it is not being argued about while your site is live.

Dependency and security patching on a defined cadence, platform and OS-release compatibility work, monitoring with an agreed incident response time, and a budgeted allowance for small changes each month. You also get a written monthly summary of what shipped and what is next, so the retainer is visible rather than a standing invoice.

That is a legitimate choice and plenty of clients make it. You get a documented CI/CD pipeline your own team or your next developer can run, and a handover written so they do not need to call me. The only thing I ask is that the decision is made knowingly — software rots even when nobody touches it, because dependencies get CVEs and platforms deprecate APIs.

Yes, and under staff augmentation that is an explicit goal rather than a favour. Handover includes a recorded walkthrough of the admin surfaces, architecture notes, the decision log, and as many working sessions as your team needs. Knowledge that leaves when the contractor leaves was never really transferred.