Software engineering studio
Multi-language IVR workflows, web apps, and AI automation — built to be handed over.
Webilogic builds the telephony, web, and backend systems businesses run on — call flows that work in every language your callers use — then hands them over with the code in your repository and the infrastructure in your cloud account. 9 years of engineering, 5 of them on telephony.
- Build
- IVR · Web · Backend · AI
- Languages
- TTS and pre-recorded
- Platforms
- AWS · Azure · Twilio
- Stack
- Node.js · React · Python
- Handover
- Your repo, your cloud
- Reply
- Within one business day
- Amazon Connect
- Twilio
- AWS & Azure
- Node.js
- React & Next.js
- Amazon Bedrock
What we build
Six practices, one delivery team
Most projects touch more than one of these. They are listed separately because the scope of each is different, not because they get sold separately.
IVR Workflows & Multi-language Call Flows
Phone systems that answer, route, and actually resolve calls — in every language your callers use, built on Amazon Connect, Twilio, or Asterisk.
- Amazon Connect
- Amazon Lex
- Amazon Polly
- Twilio
Web Applications
Dashboards, admin panels, customer portals, and product front ends — React and Next.js, typed end to end, fast on the devices your users actually have.
- React
- Next.js
- Angular
- TypeScript
Backend & APIs
Node.js services, REST and GraphQL APIs, queues, and the data layer underneath — designed to be operated, not just deployed.
- Node.js
- NestJS
- Express
- .NET
AI Automation
LLM agents, chat and phone assistants, and document workflows wired into the systems you already run — with the fallback path designed before the happy path.
- Amazon Bedrock
- Amazon Lex
- Hosted LLM APIs
- Vector search
Cloud & DevOps
AWS and Azure infrastructure as code, CI/CD, containers, and monitoring — so deploys are boring and the bill is predictable.
- AWS
- Azure
- Docker
- Kubernetes
Integrations & Data
Making systems that were never designed to talk to each other exchange data reliably — including what happens on the days they disagree.
- Node.js
- Python
- PostgreSQL
- Redis
Where it runs
An IVR is not an industry — it is a building block
A number, a call flow, a routing decision, and a lookup against your data. What changes between sectors is the system it reads from and the words it says.
Healthcare & home care
Appointment reminders and confirmations, prescription lines, and telephony EVV for Medicaid home care — caregiver clock-in by phone, with visit data submitted to state aggregators.
Logistics & delivery
Shipment status by phone, driver check-in and proof-of-delivery capture, automated dispatch notifications, and exception calls when a route slips.
Banking & fintech
OTP by phone call and step-up verification, balance and transaction enquiries, card block and dispute flows, and routing that identifies the caller before an agent answers.
Retail & e-commerce
Order status without an agent, returns initiation, store locator and hours, and callback rather than a hold queue during a sale.
Utilities & field service
Meter readings by keypad, outage reporting and status lines that absorb a spike, and appointment windows confirmed by automated call.
Education & public services
Admission and results enquiry lines, absence reporting, multi-language helplines, and broadcast calls that do not fall over on the day they matter.
Not on this list? The question that decides feasibility is not your industry — it is whether the data the caller needs is reachable over an API. If it is, the call flow is the straightforward part.
Reference architecture
An AI-enabled healthcare contact center on Amazon Connect
The shape most telephony projects converge on, whatever the industry. The full walkthrough covers component choices, latency budgets, the data boundary, and the cost model.
- 01
Ingress
A carrier DID or SIP trunk terminates on Amazon Connect. Numbers stay portable; the carrier is a decision, not a lock-in.
- 02
Contact flow
Connect owns routing, hours, queues, and recording. The existing DTMF menu stays intact underneath as the failure path.
- 03
Intent
Lex handles the intents worth modelling, with slot validation and a confidence threshold that is tuned, not defaulted.
- 04
Fallback
Below threshold, a Bedrock agent takes the turn with tool access and redacted logging, then returns to the same fulfilment path.
- 05
Fulfilment
Lambda reaches your systems of record over your own APIs. The interaction is written before the call ends, not after it.
- 06
Submission
Events go to downstream systems on their schedule, and rejections come back into a reconciliation queue rather than an inbox.
How we work
Five steps, and what each one leaves you with
The shape is the same whether the project is a two-week call flow or a nine-month platform. Only the length of step three changes.
- 01
Scoping call
Forty-five minutes with an engineer in the room. We look at the system rather than a description of it, and say plainly whether this is work we should take.
→ A written summary and next step
- 02
Discovery
Current-state review, target architecture, and the sequence — what depends on what, what to leave alone. Paid, short, and yours to keep whether or not the build follows.
→ Architecture and plan document
- 03
Build in the open
Weekly demos against working software, commits in your repository from day one, and a staging environment you can click through whenever you like.
→ Working increments, every week
- 04
Cutover
A rehearsed switch with a rollback at each step. For phone systems that means a parallel run, with traffic moved deliberately rather than all at once.
→ Runbook and rollback plan
- 05
Handover
Infrastructure as code, documentation, and training for whoever operates it next. Support afterwards is a separate, optional retainer — not a dependency we design in.
→ Docs, IaC, and admin training
Who you would be working with
Sanket Gajera, founder and lead engineer
9 years building software, 5 of them on IVR and telephony in production — contact centers, IVR systems that thousands of people call every morning, and the backends behind them. Webilogic is a small senior team, and the person who scopes your project is the one who builds it.
We take a limited number of projects at a time. If one needs more hands than we have, we say so before signing rather than after.
How we work, in detailQuestions
What people ask on the first call
What does a project cost?
There is no price list, because the same sentence — “we need an IVR” — covers a two-week call flow and a nine-month platform. Cost tracks four things: how many screens or call flows exist, how many systems have to be integrated, how much of the current data is trustworthy, and whether anything has to be live before a fixed date.
You get a written quote after a scoping call, with the scope, the exclusions, and the acceptance criteria attached to it. If the budget you have in mind will not buy what you have described, we say so on the call rather than in a proposal three weeks later.
Which industries do you build IVR systems for?
Any of them. An IVR is a number, a call flow, a routing decision, and a lookup against your data — the parts that change between industries are the words and the system it reads from.
We have shipped this for healthcare and home care, logistics, financial services, retail, utilities, and public helplines. The healthcare work happens to be the most regulated version, which is why the failure paths get designed first regardless of who is calling.
Can you add AI to our existing system without replacing it?
Yes, and that is usually the right sequence. On a phone system, a speech or LLM layer is invoked at the point where your menu sits today, and the existing keypad tree stays as the fallback path. On a web product, an assistant sits beside the current interface rather than in front of it.
A first phase covers the handful of intents or tasks that account for most of the volume — not the whole surface. Everything else keeps working exactly as it does now, and there is a measured before-and-after rather than a claim.
Do you work with our existing team or replace them?
With. Projects are written to end with your engineers owning the system: infrastructure as code, documentation, runbooks, and review sessions while it is being built rather than a handover document at the end.
If your team will not have the capacity to own it afterwards, that is worth knowing in week one. We raise it during scoping, not after launch.
Who owns the code and the cloud account?
You do, on both counts. Code lives in your repository from the first commit, and we build in your AWS or Azure account rather than ours, so nothing has to be migrated at the end and nothing is hostage to a renewal.
Where we hold credentials during a project, they are scoped to what the work needs and revoked at handover.
How do you handle data protection and compliance?
Data stays in your account, in the region you choose, encrypted at rest and in transit, with least-privilege access per component and an audit trail switched on. Nothing is copied to a workstation and nothing reaches a third-party service that has not been agreed in writing.
For regulated work we have built to HIPAA expectations on healthcare telephony — a signed BAA, PHI kept out of logs, redaction before anything reaches a model provider, and a stated retention policy on recordings. The same shape applies to PCI or GDPR obligations: the controls are specific, they are written down, and they are testable.
How do projects start?
A 45-minute call — bring an engineer, not only a buyer. We want to see the system, not a summary of it.
Larger builds start with a short paid discovery: current-state review, target architecture, and a sequenced plan with an estimate you can take to finance. You own that document whether or not the build follows. Smaller, well-defined pieces skip straight to a fixed scope and a start date.
Do you support the system after launch?
Yes, on a monthly retainer covering monitoring, incident response, dependency and security updates, and a block of hours for changes. It is optional and priced separately — some teams take the handover and run it themselves, which is a good outcome.
Production incidents are covered 24/7 for production incidents.
Where are you based, and how does the time difference work?
We are based in India and contract with clients in the US, UK, and Europe directly, in your currency and under your law.
Working hours overlap 9:00am–1:00pm ET, every weekday, messages are monitored to 6:00pm ET, and production incidents are covered 24/7 for production incidents.
In practice the distance costs one thing: we do not take 8am ET stand-ups. Design reviews, demos, cutover calls, and incident bridges all happen inside the overlap or on escalation.
Bring an engineer to the first call
Forty-five minutes, no deck. Tell us what the system is now and what has to be true in six months, and you will leave with an opinion you can act on whether or not you hire us. Replies within one business day.
Prefer email? webilogic.tech@gmail.com — same response time.