Questions people actually ask
before they hire me.

It depends on the architecture, not the technology. Self-hosted n8n keeps orchestration and stored data on infrastructure you control. Anything sent to a language model leaves that boundary, so I scope which fields are actually needed and strip the rest before the API call. Sensitive records can be processed by reference rather than content.

In every engagement I have delivered, it meant the same people stopped doing data entry and started doing review, exceptions, and client work. Automation removes tasks, not roles. If the goal is genuinely headcount reduction, say so up front, because that changes which processes are worth automating first.

Workflows are built with error handling and failure notifications, so a break surfaces immediately instead of quietly producing wrong output. I include a maintenance window after handover, and full documentation so your team or another developer can take it over. You own the workflow files outright.

The test is not company size, it is task frequency. A five-person firm generating forty quotations a month benefits more than a fifty-person firm generating four. If nobody on your team spends several hours a week on a repetitive, rule-based task, automation is not your bottleneck and I will tell you that.

No. Automation sits between the tools you already use rather than replacing them. Most builds connect Google Sheets, email, a CRM, and accounting software that the business has used for years. Replacing working systems is expensive and rarely necessary to get the process gain.

No, and neither can anyone else honestly. Rankings depend on competitors who also act, and on algorithm changes nobody controls. What I commit to is the work, monthly reporting against agreed targets, and telling you early if a term is not winnable so budget moves somewhere it can perform.

Usually not. Most sites have fixable technical problems rather than fatal ones. A rebuild only becomes the cheaper option when the platform blocks fundamentals — no control over page titles, unfixable page speed, or URLs that change on every edit. The audit tells you which situation you are in.

Fewer, better pages beat volume. A page that fully answers one buyer question and links sensibly to related pages outperforms ten thin posts covering the same ground. For most Nepali businesses, two well-researched pages a month sustains steady growth without diluting the site.

No. Paid link networks are the fastest route to a manual penalty, and recovery takes longer than the ranking was ever worth. Links are earned through content worth citing, local partnerships, industry directories, and press — slower, but it does not put the domain at risk.

Organic traffic, rankings for agreed terms, enquiries attributed to organic search, work completed, and what is planned next. The enquiry number is the one that matters. If traffic rises while enquiries stay flat, that is a problem to address, not a result to celebrate.

No. AEO sits on top of SEO and depends on it — a page that cannot be crawled or does not rank at all will never be selected as an answer source. The technical foundation is shared. What differs is content shape and structured data.

Through Search Console impressions against zero-click queries, manual tracking of which questions return your page in the answer box, and branded search volume, which tends to rise as your name appears in more answers. It is a less tidy measurement story than rankings, and I will not pretend otherwise.

Faster than conventional SEO in most cases. Answer surfaces re-evaluate frequently, so a well-structured block on an already-indexed page can appear within 4 to 8 weeks. Pages that need to earn indexation first take longer.

Shorter blocks get passed over for a competitor with more substance; longer ones get truncated mid-thought when extracted. That band is where an answer stays complete inside the space these surfaces allocate. It is a working heuristic from observation, not a published Google rule.

A plain-text file at the root of your site summarising what your business does, in a form language models can read without parsing your HTML. It is an emerging convention rather than a ratified standard, but it costs almost nothing to publish and removes ambiguity about who you are.

That is a genuine strategic choice, not an obvious mistake. Publishers whose product is the content itself often should block. A services business whose content exists to generate enquiries almost never should — blocking guarantees you are absent from answers your competitors appear in.

By testing a fixed set of category questions across ChatGPT, Claude, Perplexity, and Gemini each month and recording which sources are cited, alongside branded search volume and referral traffic from AI platforms. It is less precise than rank tracking, and I report it as the directional signal it is.

Typically 2 to 4 months. Models retrain and re-crawl on their own schedules, and Perplexity, which searches live, reflects changes far faster than a model relying on training data. Crawler access fixes can show up within weeks.

Spend, reach, engagement, and — the number that matters — enquiries generated and their cost. If reach rises while enquiries stay flat, that appears in the report as a problem to solve rather than being presented as a win.

Strategy, copy, and campaign structure yes. For heavy video and photography production I bring in specialists rather than pretending otherwise — a phone-shot reel works for some categories and actively damages others, and knowing which is part of the job.

Three months, because anything shorter cannot produce a fair read. The first month is setup and baseline, the second gathers data, and the third is the first month where optimisation is based on evidence rather than assumption.

You do. Accounts are created under your business, with access granted to me rather than the reverse. If the engagement ends, your campaign history, audiences, and pixel data stay with you — that accumulated data is often worth more than the campaigns themselves.

A standard business site takes 4 to 8 weeks. The build is rarely the bottleneck — waiting on content, photography, and approvals usually is. Projects where the client has copy ready at kickoff finish noticeably faster than ones where writing happens alongside development.

Usually Vercel or a similar platform with a global edge network, which serves Nepali visitors faster than a single origin server. Hosting is set up under your own account so you retain control, and ongoing cost for a business site is modest.

For a statically generated site, very little — there are no plugins to patch and no database to secure. Content updates, dependency upgrades a few times a year, and monitoring. Maintenance retainers are available but genuinely optional, which is not true of a plugin-heavy WordPress build.

Yes — eSewa, Khalti, and card gateways including Stripe for international sales. Payment integration adds meaningfully to timeline and cost because it needs careful testing against real transactions, so it is scoped separately rather than bundled in.

A straightforward cross-platform app takes 10 to 16 weeks to first release. Add 2 to 3 weeks for store review and the fixes reviewers request — Apple in particular rejects first submissions routinely, and building that round trip into the timeline avoids an unpleasant surprise near launch.

Yes, including store listings, screenshots, privacy declarations, and the review process. Developer accounts are registered under your business rather than mine, so you own the listing outright and are never dependent on my account to publish an update.

Yes, and in Nepal it usually should. Offline-first architecture stores data locally and syncs when connectivity returns, so a user filling a form on an intermittent connection does not lose their work. It adds complexity and cost, and for most Nepali users it is worth both.

Android and iOS both require compatibility updates roughly annually, and an app left unmaintained will eventually be delisted or stop functioning on new devices. Budget for ongoing maintenance from the outset rather than treating it as an optional extra later.

You do, transferred on final payment along with repository access, deployment configuration, and documentation. Nothing runs on infrastructure only I can access. If you later want a different developer to take over, they can — that is the point.

A focused internal tool takes 8 to 16 weeks. A multi-role platform runs 4 to 9 months. I structure delivery so something usable reaches real users within the first 6 to 8 weeks, because feedback from actual use is worth more than any amount of upfront specification.

Usually. Anything with an API integrates cleanly. Older Nepali systems sometimes have none, in which case options are scheduled file exchange or database-level integration — both workable, both adding cost. This gets assessed during scoping rather than discovered mid-build.

The build uses mainstream technologies with documentation written for a developer who was not involved. Deliberately boring choices — TypeScript, PostgreSQL, standard framework patterns — because clever architecture that only its author understands is a liability once handed over.

Sometimes the honest answer is that I could build it, and I say so explicitly and let you decide. More often the recommendation is an existing product or a different specialist. Where a recommendation would benefit me, that is stated in the report rather than left implicit.

A written assessment with a clear recommendation, the reasoning behind it, and the risks of each option — not a slide deck of observations. Short enough that a busy director reads all of it, specific enough to act on without a follow-up meeting.

No. Small organisations often benefit more, because a single wrong system choice is proportionally far more damaging when there is no budget to correct it. A two-day engagement is a legitimate size and I take that work.

Yes — technical due diligence on delivered systems, including code review, architecture assessment, and whether what was delivered matches what was contracted. Findings are reported factually, since the goal is a working outcome rather than assigning blame.