Frequently asked questions

It starts with understanding your process rather than your feature list. We map how the work is done today, write a specification you can read and correct, agree the screens, then build in short cycles with working software to review throughout. Testing, deployment and a period of support follow.

You describe the problem; we ask questions about how the work is done now and where it breaks. By the end you should have a clearer idea of what is involved and roughly what it would take. There is no obligation, and if we think you would be better served by an existing product we will say so.

No. Most useful projects start from a problem rather than a specification. Writing the requirements is part of the work, and doing it together usually produces a better result than receiving a finished document.

Yes. We work with businesses in West Bengal and beyond. Most collaboration is remote, with on-site visits where a project genuinely benefits — process mapping, plant walkthroughs and training sessions in particular.

It depends on scope, and any figure quoted before understanding the scope would be a guess. We give a written quotation against a written specification, so you can see what is included and what is not. Fixed-price, retained and phased arrangements are all available.

A focused internal tool is typically a matter of weeks. A departmental system with integrations usually runs to a few months. Large multi-module platforms are delivered in phases so something useful goes live early rather than everything arriving at the end.

Changes are expected — requirements become clearer once people see working software. On a fixed-price project each change is quoted before it is done. On a retained arrangement priorities can simply be reordered within the agreed capacity.

Payments are staged against delivery milestones agreed in advance, so payment follows progress you can see rather than a calendar.

Commonly React, Next.js and Angular on the front end; Node.js, Python, PHP with Laravel, Java and .NET on the back end; Flutter and React Native for mobile; PostgreSQL, MySQL and MongoDB for data; and AWS, Azure or Google Cloud for hosting. The choice follows the project rather than a house preference.

From the requirements, your existing systems and who will maintain it afterwards. If your team already works in a particular stack, that carries real weight — a technically superior choice your people cannot maintain is not superior in practice.

Usually. We integrate with existing databases and applications regularly, and can run new modules alongside an old system with data kept in step while you transition.

Where they genuinely help — document extraction, forecasting, classification. We assess feasibility against your data first, and will tell you when conventional software would be cheaper, more predictable and easier to explain.

You do. Source code, repositories, hosting accounts and domains are registered in your name and handed over. Nothing is withheld to make you dependent on us.

Access control designed with the data model, validation of all external input, encryption in transit and at rest, secrets kept out of source control, dependency scanning, and logging of authentication and administrative actions.

Development and testing use anonymised or synthetic data wherever possible. Where real data is genuinely necessary, access is limited and agreed with you in advance.

Yes. We are happy to sign your NDA before detailed discussions begin.

Real usage always reveals adjustments. We stay available for fixes and refinements under a support arrangement scaled to how critical the system is — from occasional help through to a monthly retainer with agreed response times.

Because it decays even untouched. Dependencies acquire vulnerabilities, browsers and operating systems change, payment providers deprecate endpoints and certificates expire. Maintenance is what keeps a working system working.

Yes. We begin with a code audit so both sides understand the state of the system, then propose support based on what we actually find.

Yes, and the work is done with that in mind — readable structure, documentation and no proprietary lock-in. If you hire an internal team, handover should be straightforward.

We build the technical foundations that make ranking possible — clean markup, fast loading, correct metadata, structured data, sensible internal linking, a sitemap and no crawl obstacles. Ranking itself also depends on content and competition, and nobody can honestly promise a position.

We handle technical SEO as part of building and maintaining a site. Ongoing content and off-site work is a different discipline, and we will say so rather than sell something outside what we do well.

Yes. Sites are built with an editing layer matched to how often you publish, so routine changes do not require a developer.

Because most visitors arrive on a mid-range phone, often on a mobile connection. Slow pages lose visitors before they see anything, and page experience is a factor in how search engines rank results.