89 questions, answered directly

Kornspire is a technology company based in India that designs, builds and runs software — custom applications, SaaS platforms, and web and mobile apps — and provides the cloud, data, security and AI engineering behind them, for startups, growing businesses and enterprises in India and abroad. It also builds and operates its own SaaS product, Upkilo, and undertakes research, development and training in emerging technologies including artificial intelligence, machine learning, IoT, blockchain and robotics.

It is a new company with a product already in paid use. Kornspire Private Limited was incorporated in India in September 2026, and it runs Upkilo — our own multi-tenant SaaS platform for appointment-based businesses, with paying customers — which we designed, built, operate and license. We do not yet publish client case studies, logos or testimonials: client work appears only with the client’s consent and with real figures. What you can test before spending anything is the product, the reasoning in our technical writing, a written scope before any billable hour, and an explicit list of what we will not promise.

Sometimes you should not, and we will say so — a programme needing sector-specific regulatory experience or a large parallel team is better served elsewhere. Where a firm of our size is a genuine advantage is engagements that reward senior attention: you deal directly with the people doing the work, scope is written rather than inherited from a template, and there is no incentive to extend an engagement past its useful life. Judge the reasoning in this site's technical writing and the product we run, then test both against a small, well-defined piece of work.

Kornspire is based in India and works with organisations in India and abroad, which is part of the company's stated business objects. Engagements are delivered remotely by default, with on-site time where the work genuinely requires it — plant-floor systems, field operations and in-person workshops being the usual cases.

With a conversation about the outcome and the constraints, followed by a written scope before any billable work. For larger or less certain problems, the sensible first step is usually a fixed-scope assessment: you get a prioritised written report you can act on with any supplier, and both sides learn how the other works before committing to a longer engagement.

You do. Work is delivered into repositories and cloud accounts you control, with third-party dependency licences documented. Nothing we build requires continued access to a Kornspire-hosted system unless you have specifically chosen a managed service.

No. Ranking and generative-answer placement are decided by systems no supplier controls, and any guarantee of them is either a misrepresentation or a plan that risks a penalty. What we commit to is the engineering: crawlability, rendering, structured data, performance, entity consistency and citable content structure — measured before and after, and reported honestly.

Primarily TypeScript and React with Next.js on the web; .NET, Node.js and Python for services; React Native for mobile; PostgreSQL and SQL Server for data; and Docker, Kubernetes and Terraform on Azure or AWS. We choose from what fits the problem and your team's ability to maintain it, and we will recommend a stack we do not favour when it is the better fit for you.

SEO optimises whether a page can be crawled, indexed and ranked in a list of search results. AEO optimises whether a specific passage can be extracted and used as the direct answer to a question, in an answer box or a voice response. GEO optimises whether generative AI systems describe your organisation accurately and cite your content when they write an answer about your category. They share a technical foundation — crawlable, well-structured content — and diverge in what they optimise: the page, the passage, and the entity respectively.

Not necessarily, and not simultaneously. The technical foundation is non-negotiable because all three depend on it. Beyond that, the priority follows how your buyers actually search: high-intent commercial queries argue for SEO first; a high volume of repeat questions argues for AEO; and a category where prospects arrive quoting an AI assistant argues for GEO. Doing the foundation properly advances all three at once.

Technical SEO fixes usually move first, because changing what search engines can access can show up within days to a few weeks. AEO restructuring tends to read over several weeks as pages are re-crawled and re-evaluated. GEO is the slowest and the least directly attributable, because generative systems update their view of an organisation gradually and non-deterministically. Any timeline more precise than that is a guess dressed as a commitment.

There is no evidence for that, and the dependency runs the other way. Generative systems draw on content they can crawl, parse and attribute, so a site that conventional search engines cannot reach is largely invisible to AI assistants as well. What is changing is the share of attention across surfaces — which makes the shared technical foundation more valuable, not less.

Configuration adapts your process to the product's model; custom software encodes your model directly. Configuration is usually cheaper and faster, so it is the right answer whenever your process is not a differentiator. Custom development becomes worthwhile when the process is something you compete on, when integration and data ownership matter, or when the accumulated workarounds already cost more than a purpose-built system would.

You do. Work is delivered into a repository you control, with the licence position for every third-party dependency documented. Nothing in a delivery depends on continued access to a Kornspire-hosted account or a proprietary runtime unless you have explicitly chosen a managed arrangement.

Yes. That starts with a code and infrastructure audit: dependency health, test coverage, security posture, deployment path and the risks that come with them. You get a written assessment with a prioritised remediation plan before any code changes, so the decision to continue, refactor or replace is an informed one.

By treating documentation, automated tests, dependency updates and architecture decision records as part of delivery rather than optional extras. A system becomes legacy when nobody can safely change it — so the deliverable is not just working software, it is software your own team can still change in three years.

Next.js with React and TypeScript is our default for product-grade sites, because it lets each route choose its own rendering strategy and gives strong control over performance and metadata. The default is not dogma: a brochure site with little interactivity may be better served by a simpler static generator, and we say so when that is the case.

Yes. Content that changes regularly is modelled and moved into a headless CMS with editorial preview, so publishing is a content task rather than a deployment. We document the model and train the people who will use it.

Included. Semantic structure, keyboard operability, focus visibility, contrast and reduced-motion support are part of the build and part of the definition of done. WCAG 2.2 AA is the working standard; where a specific interaction cannot meet it, we document the limitation rather than quietly ship it.

Often, yes — and it is usually the cheaper answer. We audit performance, accessibility, crawlability and code health first, then propose the smallest set of changes that moves the metrics that matter to you. A rebuild is recommended only when the existing foundation makes those changes more expensive than replacing it.

By what the product actually depends on. If it is mostly data, forms, lists and notifications, a shared React Native codebase delivers both platforms for materially less cost and keeps behaviour consistent. If it depends on sustained camera or sensor processing, complex platform-specific UI, or the newest OS APIs, native is the correct choice. Hybrid is also valid: React Native shell with native modules where they earn their place.

Frequently not. A well-built responsive site or installable web app covers many mobile needs at a fraction of the cost and with no store review. An app is justified when you need genuine offline operation, hardware access, background processing or reliable push notifications. We will say when a website is the better investment.

Publishing happens under your own Apple and Google developer accounts, so the listing, the reviews and the signing identity remain your property. We prepare the builds, assets and submission material, and handle review feedback with you.

Apple and Google change platform requirements every year, and an app that is not maintained eventually stops being distributable. Maintenance covers OS and SDK upgrades, dependency and security updates, crash triage, store policy changes and periodic device-matrix testing.

It depends on the isolation your customers require and the operational cost you can carry. A shared schema with enforced row-level scoping is the cheapest to operate and the most efficient, and suits most products. Schema-per-tenant eases per-customer data export and restore. Database-per-tenant gives the strongest isolation and the highest operational cost, and is usually driven by regulatory or enterprise procurement demands. The decision is recorded with its trade-offs, because it is difficult to reverse later.

Yes, and it is common. It begins with an assessment of where tenant identity would have to reach: the data model, every query path, caches, background jobs, file storage, exports and the audit trail. That produces a staged plan — usually enforcing isolation at the data-access layer first, then provisioning, then billing — rather than one high-risk rewrite.

By metering at the source of the event rather than inferring usage afterwards, storing raw metering records immutably, and reconciling aggregates against them on a schedule. Billing disputes are then answerable from data instead of from argument.

Yes. Upkilo is our own product — a multi-tenant booking, CRM, payments and marketing platform for appointment-based businesses such as salons, spas and clinics. We designed it, built it, and we operate, support and license it. That means the decisions described on this page are not theoretical for us: the tenancy model, the billing pipeline, the onboarding flow, the release process and the support cost are all things we have had to get right and then live with.

In practice: SSO, provisioning and role mapping, audit logs a customer can export, data residency answers, a documented backup and restore position, published service-level objectives, and a security questionnaire you can complete without improvising. We build towards that list deliberately, because it is what procurement actually asks for.

Sometimes the honest recommendation is work we can do, and sometimes it is not. We state the recommendation, the reasoning and the alternatives — including keeping your current system, hiring internally, or buying a product — so you can judge it. Advisory deliverables are written to be executable by any competent team.

For a focused question — one platform, one decision — typically two to three weeks. A full estate assessment across many systems and stakeholders usually runs four to six weeks. The scope and the questions to be answered are fixed in writing before the engagement begins.

Access to the people who operate the systems, read access to code and infrastructure where relevant, and visibility of contracts and spend. Where access cannot be granted, we record the resulting gap explicitly rather than filling it with assumption.

The one that fits your workload, your team's existing skills and your data-residency requirements — most commonly Azure or AWS, with Cloudflare for edge delivery. We do not hold a reseller position with any provider, so the recommendation is based on fit rather than margin. Where multi-cloud is proposed, we usually argue against it unless there is a concrete requirement driving it, because the operational cost is consistently underestimated.

Yes, as a managed service with defined response commitments, or as a co-managed arrangement where your team holds day-to-day control and we handle escalation and periodic review. Both are documented, and both leave access and ownership with you.

They should be derived from business impact, not chosen for comfort. We help you set a recovery point objective and recovery time objective per system, implement backups that can meet them, then rehearse a restore to prove it. An untested backup is an assumption, not a control.

It varies too much for an honest number in advance, and we will not quote a percentage we cannot substantiate. Untuned estates commonly carry idle capacity, oversized instances and unmanaged storage growth. We measure first and present findings with the specific saving and the risk attached to each change.

If reporting is light and does not interfere with the application, a read replica and well-chosen indexes are often sufficient — and far cheaper to operate. A warehouse earns its place when you need to combine several sources, keep history that the transactional system overwrites, or run analytical queries that would otherwise degrade production.

Yes. The governed model and metric layer are the durable assets; the visualisation tool sits on top and is comparatively easy to change. We build so that replacing the front end later does not mean rebuilding the definitions.

By classifying it at ingestion, minimising what reaches the analytical layer, pseudonymising or aggregating where the analysis does not need identity, applying retention rules, and restricting and auditing access. This is designed against India's DPDP Act 2023 and, where relevant, GDPR — with your legal advisers confirming the obligations that apply to you.

Three things, none of them visual: a definition the reader can see, a freshness indicator that shows when the data last updated, and tests that fail loudly when an assumption breaks. Without those, a dashboard is a rendering of unverified numbers.

Our focus is defensive engineering — design review, hardening, secure development practice and incident readiness — rather than adversarial testing as a standalone product. We review and test systems only within an agreed, written scope and with the owner's authorisation. Where a formal third-party penetration test or certification audit is required, we prepare you for it and help remediate the findings.

We can implement and evidence the technical controls those frameworks expect — access management, logging, change control, encryption, backup and recovery, dependency management — and help assemble the evidence. Certification itself is issued by an accredited auditor, not by us, and we will not imply otherwise.

By exploitability in your specific environment and the business impact if exploited, not by scanner severity alone. A medium-severity issue reachable without authentication on an internet-facing service usually outranks a high-severity issue that requires administrative access to exploit.

We implement the engineering side: data mapping, minimisation, retention and deletion, access control and audit, encryption, and breach-detection readiness. The legal determination of your obligations under India's DPDP Act 2023 or GDPR belongs with your legal advisers; we build and evidence the controls that support it.

Only when nothing better is available. Screen-driven automation is brittle — it breaks when a vendor changes a layout — so we prefer an API integration or a workflow engine wherever one exists. Where a system genuinely offers no programmatic interface, we will use UI automation and be explicit about its fragility and maintenance cost.

In the work we see, the realistic outcome is a shift in what people spend time on: fewer re-keying and chasing tasks, more exception handling and judgement. We do not present automation as a headcount argument, and we design an explicit path for the cases automation should not decide.

With a process that is high-volume, rule-based, stable and measurable. Those four properties predict success better than any technology choice. Low-volume processes with many exceptions rarely repay the effort of automating them.

Something narrower than the phrase usually implies. In our engagements it means changing a specific set of processes, the data that supports them and the roles around them — with measurable before-and-after outcomes. If a proposal cannot name the processes it will change and how the change will be measured, it is not a transformation plan.

Response times are agreed per engagement and tied to severity, with the highest severity reserved for a production outage or data-integrity issue. We commit to response and communication intervals, and to a defined escalation path. We do not quote a blanket resolution guarantee for every defect, because resolution time depends on cause — and a promise we cannot keep is worse than none.

Yes, subject to a short assessment. Some systems can be supported immediately; others need specific gaps closed first — typically monitoring, deployment repeatability or backup verification — because supporting them otherwise would be a false assurance. The assessment tells you which case you are in before any commitment.

Usually as a monthly retainer sized to the system's scope and the response commitments you need, with an allocation for improvement work. Where volume is genuinely unpredictable, a time-and-materials arrangement with an agreed cap can be the fairer structure.

Documentation, runbooks, infrastructure code and access remain yours throughout, so a handover is an administrative exercise rather than a dependency negotiation. We will run the handover with the incoming team.

Retrieval first, in almost every case. Most business requirements are about grounding answers in your own current data, which retrieval addresses directly, cheaply and with citations — and your data can change without retraining. Fine-tuning is appropriate for consistent format or style, for a narrow specialised task, or when latency and cost at high volume favour a smaller specialised model. The evaluation set decides, not preference.

By grounding responses in retrieved source passages and citing them, instructing and testing for refusal when the sources do not support an answer, validating output structure, and scoring confidence so low-confidence cases route to a human. These reduce fabrication substantially; they do not eliminate it, and we do not claim they do. Any feature whose wrong answer would be consequential keeps a human in the loop.

That is modelled before build, not discovered afterwards. Cost per request depends on model choice, input size, retrieval strategy and cache hit rate; we measure it on your evaluation set, project it to your expected volume, and set budget alerting. Where cost is the binding constraint, we optimise for it explicitly — usually through a smaller model, tighter retrieval and caching.

You do. We document which data is sent to which provider, what that provider's retention and training position is, and where processing physically happens — so data-residency and DPDP Act questions have written answers. Where those constraints require it, self-hosted or regional model deployment is designed in instead.

Usually not, and we will say so. A distributed ledger earns its place when several parties who do not fully trust each other must share a record with no single accepted operator. If one organisation is the natural custodian, a well-designed database with signed, append-only audit records gives the same integrity guarantees at a fraction of the operational and regulatory cost. We evaluate the trust model before the technology.

It is deliberately bounded: a stated time box, usually four to eight weeks, with a cost ceiling agreed in advance. If the hypothesis is disproved early, the engagement ends early and you keep the finding. We do not structure research as open-ended work.

Yes. Prototype code, designs and findings are delivered to you, with third-party licences and their obligations documented. Where a reusable component would be better licensed than transferred, we raise it before the work starts rather than after.

Yes — but as a separate, deliberately scoped engagement, because a prototype is built to answer a question and production software is built to be operated. The cost-to-production estimate in the research findings is what that engagement is scoped against.

No. We are not an accredited certification body and will not imply that we are. Our training is practical enablement measured by changed practice in your team's work. Where a formal certification is what you need, an accredited provider is the right route and we will say so.

Workshops work best with roughly six to twelve participants, because everyone needs to be doing the exercises rather than watching them. Larger groups are viable for briefing-style sessions, and we will be clear about the difference in what each format achieves.

Yes, and it works well when sessions are kept shorter, split across days and built around exercises rather than presentation. In-person is preferable for deep pair-work sessions where reading the room matters.

Training is substantially more effective with read access to representative repositories, under whatever confidentiality terms you require. Where access cannot be granted, we build exercises on a close analogue and note the gap that remains.

No, and nobody honestly can. Ranking is decided by search engines using signals no vendor controls, including competitors' behaviour. What is controllable is whether your site is crawlable, renderable, fast, correctly structured and genuinely useful — and that is what we engineer. Any supplier who guarantees a position is either misrepresenting their influence or planning something that risks a penalty.

No. Off-page link acquisition, paid search, social media management and PR fall outside our scope, and outside the company's registered business objects. Our work is engineering on your own platform: crawlability, rendering, architecture, structured data, performance and content structure. Where off-page work is genuinely needed, a specialist agency is the right partner and we will work alongside them.

Indexation and crawl fixes often show movement within days to a few weeks, because they change what search engines can access. Ranking and traffic changes follow re-crawling and re-evaluation and typically take longer, commonly one to three months to read reliably. We report what the data supports and distinguish clearly between a technical fix that is verified and a traffic change that is inferred.

Yes, and increasingly so as a dependency. AI answer systems draw heavily on content they can crawl, parse and attribute — so a site that search engines cannot reach is also largely invisible to them. Technical SEO has become the shared foundation underneath conventional search, answer engines and generative assistants alike.

SEO aims to get a page ranked as a result; AEO aims to get a specific passage used as the answer. They overlap — a page usually has to be indexable and reasonably ranked before it is eligible for extraction — but the work differs. SEO is largely crawl, render, architecture and performance; AEO is question ownership, answer placement, phrasing and markup.

Far less often than it once did. Since August 2023, Google shows FAQ rich results only for well-known, authoritative government and health websites, so treating FAQPage markup as a route to visual rich snippets is outdated advice. It remains worthwhile as clear machine-readable structure for answer systems, and the answer-first content pattern retains its value independently of whether any rich result is displayed.

It often does, because the same restructuring that makes an answer extractable also makes it findable by a customer. We usually measure this alongside search metrics: repeat-question volume is frequently a more meaningful indicator than an impression count.

Either. Your subject-matter experts hold the accurate answers, so the strongest arrangement is usually that they supply substance and we structure, phrase and mark it up. We do not publish claims about your business that you have not verified.

No. No supplier can guarantee placement in a generative answer: the systems are non-deterministic, they change without notice, and none of them sells ranking. What can be done is make your organisation unambiguous, factually consistent and genuinely citable, and then measure what assistants say over time. Any guarantee of AI rankings should be treated as a warning sign.

It shares a foundation and diverges in emphasis. Both need crawlable, well-structured content. SEO optimises a page's standing in a ranked list; GEO optimises whether a system that is writing an answer treats your content as a reliable, attributable source about a clearly identified organisation. Entity consistency, factual specificity and citability matter more in GEO than any conventional ranking factor.

It is a proposed convention, not a standard that major AI systems commit to honouring, and it is not a substitute for ordinary crawlable content and structured data. We will add one because it is cheap and can help agents orient themselves, while being clear that it is not the mechanism doing the work. Anyone presenting llms.txt as an AI-visibility solution is overstating it.

It is a genuine trade-off and it belongs to you. Blocking protects content from being used for training and summarisation; it also reduces the chance of being cited in answers that reach potential customers. A common middle position is to permit access to public marketing and educational content while restricting proprietary or gated material. We implement whichever position you choose and document it.

By repeating a fixed set of prompts across the major assistants on a schedule and recording whether you are mentioned, whether the description is accurate, and which sources are cited, alongside Bing Webmaster Tools' Copilot citation report where it applies. It is mostly sampling rather than analytics, and we present it as such — with the prompt set published so the numbers can be checked.

We build the engineering controls that lawful handling depends on: data classification, purpose-limited collection, role-based access with audit, encryption in transit and at rest, retention and deletion rules, and breach-detection readiness. The legal determination of your obligations — under India's DPDP Act 2023 and any other applicable regime — rests with your legal advisers and, where required, your data protection officer. We implement and evidence the controls; we do not provide legal advice.

Where the incumbent system exposes an interface, yes — API, database view, standards-based exchange such as HL7 or FHIR, or file-based transfer. The first step is establishing what the existing system actually permits, because vendor documentation and reality often differ. That assessment comes before any integration commitment.

Both, and the choice should be driven by where your differentiation lies. A hosted commerce platform handles catalogue, checkout and payments well and is usually the right base. Custom engineering earns its place in the layers around it — storefront performance, integration with warehouse and ERP systems, pricing logic, or a headless front end when the platform's templating becomes the constraint.

By deciding deliberately which filter combinations deserve an indexable URL, based on genuine search demand, and then enforcing that with canonical tags, robots directives and internal linking. Left unmanaged, facets generate combinatorial URLs that consume crawl budget and dilute signals across pages that should have been consolidated.

The data layer is designed for it before any screen is drawn: work is stored locally, actions queue as intent rather than as completed writes, and conflicts resolve by explicit rules instead of last-write-wins. The application also shows sync state honestly, so a driver knows whether a delivery has actually been recorded.

Usually, yes. Carrier integration frequently means scheduled file exchange, email-attached documents or a legacy endpoint. We build an integration layer that normalises those inputs, retries safely, quarantines what it cannot parse, and reports reconciliation differences rather than silently dropping records.

No. We are an engineering firm, not a compliance authority or a licensed advisory. We build and evidence technical controls — auditability, access control, encryption, reconciliation, retention — and support your compliance function and auditors with the documentation they need. Interpretation of regulatory obligations belongs with your compliance and legal advisers.

With idempotency keys on every externally triggered operation, append-only records where corrections are made by reversal rather than edit, exactly-once processing semantics at the integration boundary, and scheduled reconciliation that reports breaks instead of assuming agreement. These are design decisions taken at the start; they are difficult to add to a system that did not begin with them.

Yes, if that is a design constraint from the beginning rather than an optimisation afterwards. That means small initial payloads, adaptive media quality, caching that survives a dropped connection, and interfaces that remain usable while assets are still arriving. It is tested on throttled connections and low-end devices, not only in a development environment.

With proportionate controls: randomised question selection from a bank, time limits, question-level analytics that flag anomalies for human review, and server-side answer validation. We are cautious about intrusive proctoring — it raises privacy and accessibility problems, and it disadvantages learners whose circumstances differ from the assumed norm.

It can, which is why the boundary is designed first. The default position is read-only collection at the edge, one-way data flow into the business network, strict segmentation, and no new inbound path to the plant floor. Anything that would allow a business-network system to influence production equipment is treated as a separate decision requiring explicit engineering and safety review — not a convenience to be added quietly.

Often, but it must be assessed per machine. Options range from existing protocol interfaces and vendor gateways to external sensors that observe the machine without interfacing with it at all. Where the only viable route would compromise segmentation, warranty or safety, we say so rather than engineering around the objection.