AI Web Application Development
Web applications where the AI is a feature, not the whole product.
What is AI web applications?
An AI web application is a custom web system whose useful work includes model driven features, built so that access control, cost limits and the behaviour of the product when the model is unavailable are all handled deliberately.
A web application with an AI feature is still a web application. It needs accounts, permissions, data handling and the ordinary engineering that makes software reliable, and none of that becomes less important because a model is involved.
What is different is exposure. A model driven feature on a public web page can be used by anybody who finds it, at your cost, for purposes you did not intend.
The other difference is dependence. A product whose core function requires a model has adopted that provider availability as its own, and most teams discover this during an outage rather than during design.
What we require before anything faces the public
Duara builds web applications from Nairobi for businesses that need a custom system rather than a configured off the shelf product, with AI features where they earn their place.
We will not put a model behind a public form without authentication, rate limits and a spend cap. An open AI endpoint on the internet is somebody else free compute, and the discovery is usually made through the invoice.
Who this is for
- Off the shelf software does not fit your process
- You need AI features inside a custom system
- A public facing AI feature needs protecting
- Your product must work when the model is down
Industries we serve
- Financial services
- Property and real estate
- Healthcare providers
- Education institutions
- Logistics
- Professional services
Problems this solves
These are the practical exposures of putting model driven features on the open web.
- Public AI features get abused. Anybody who finds the page can use your model at your cost, for whatever they like.
- The product depends on the provider. When the model is unavailable the whole application fails rather than losing one feature.
- Off the shelf software does not fit. The process is bent to match the tool, and the workarounds cost more than the licence saved.
- AI added without a purpose. A feature exists because it was expected rather than because it solves a problem in the workflow.
What we deliver
A custom web application built on ordinary sound engineering, with AI features protected by authentication and limits, graceful behaviour when the model is unavailable, and clear ownership of the code.
A custom web application fitted to your process
AI features protected by authentication and limits
Graceful behaviour when the model is unavailable
Role based access control
Your own hosting and your own code
Documentation and handover to your team
Features
- No unprotected AI endpoints. Authentication, rate limits and spend caps before anything model driven faces the public internet.
- The product survives an outage. Model features degrade while the rest of the application keeps working, which is a design decision made early.
- Built for your process. Custom software exists because the process is worth keeping, and we would say when an off the shelf product would genuinely do.
- Ordinary engineering still applies. Access control, testing and data handling do not become less important because AI is involved.
- You own everything. Code, repository and hosting are yours, documented so another developer could take it on.
Benefits
- Software that fits the work. The process stops bending around a tool that was never designed for it.
- Predictable AI costs. Limits and authentication keep model spend attached to real users rather than to whoever finds the page.
- Availability you control. A provider outage becomes a degraded feature rather than a stopped business.
- No lock in to us. Owning the code and the documentation means you can change supplier without rebuilding.
Technologies we use
- Web application development. Custom systems built on maintained frameworks rather than novelty.
- Authentication and access control. Accounts, roles and permissions covering AI features as well as ordinary ones.
- Abuse protection. Rate limits, quotas and spend caps on anything model driven.
- Graceful degradation. The application continuing usefully while a model feature is unavailable.
- Deployment and hosting. Running in your own cloud account with documented infrastructure.
The AI part is usually the smallest piece of the build. Most of the work is the ordinary application, and treating it as an AI project rather than a software project is how these go wrong.
How the process works, step by step
A web application usually takes eight to sixteen weeks depending on scope, with the AI features typically a small part of the estimate.
-
Step 1
Free scoping review
We look at your process, whether custom software is justified, and where AI genuinely helps.
-
Step 2
The off the shelf question
We say honestly whether an existing product would do, since custom software you did not need is expensive to keep.
-
Step 3
Core application first
The system is built and useful before AI features are added, so it stands on its own.
-
Step 4
AI features with limits
Model driven features are added with authentication, rate limiting and caps from the start.
-
Step 5
Handover with documentation
Code, infrastructure and documentation transfer to you.
Quality assurance and how we work
The commitments attached to building custom software you will depend on.
- No model endpoint faces the public unprotected. An open AI endpoint on the internet is somebody else free compute, and the discovery is usually made through the invoice.
- The application works without the model. Model features degrade while the rest keeps running, decided during design rather than during an outage.
- We say when custom software is the wrong choice. Where an off the shelf product would genuinely do, we say so rather than building something you did not need.
- You own the code and can leave. Repository, infrastructure and documentation are yours, because software you cannot take elsewhere is a liability.
- AI is a feature, not the justification. If the application only makes sense because it has AI in it, we would question whether it should be built.
Frequently asked questions about AI web applications
Should we build custom software at all?
Often not. Where an off the shelf product would genuinely do, we say so, because custom software you did not need is expensive to keep.
Can we put an AI feature on a public page?
Only with authentication, rate limits and a spend cap. An open AI endpoint on the internet is somebody else free compute.
What happens if the model provider goes down?
The AI feature degrades and the rest of the application keeps working. That is decided during design rather than during the outage.
Is this mainly an AI project?
No. The AI part is usually the smallest piece. Treating it as an AI project rather than a software project is how these go wrong.
Do we own the code?
Yes, along with the repository, infrastructure and documentation. Software you cannot take elsewhere is a liability.
Where is it hosted?
In your own cloud account, so you control access, cost and continuity rather than depending on us for it.
How long does a build take?
Eight to sixteen weeks depending on scope, with AI features typically a small part of the estimate.
Can it integrate with our existing systems?
Yes, and it usually should, since a new system that does not connect to your ERP or accounts creates a fresh island.
Can it handle M-Pesa payments?
Yes, and it is among the most common requirements in Kenyan web applications we build.
What if we only need AI in one feature?
That is the normal case and it is the right way round. The application should be worth having without it.
Will you tell us if the AI feature is unnecessary?
Yes. If the application only makes sense because it has AI in it, we would question whether it should be built.
How do you control AI running costs?
Authentication, quotas and spend caps, so model usage is attached to real users rather than to whoever finds the page.
Can different users see different data?
Yes, through role based access control, applied to AI features as well as ordinary ones.
Does it work on mobile browsers?
Yes, and given Kenyan usage patterns we treat mobile as the primary case rather than an adaptation.
Can our own developers maintain it?
Yes. We build on maintained frameworks and hand over documentation, rather than leaving something only we understand.
What about data protection?
Data stays in your infrastructure, and what is sent to a model is scoped deliberately rather than by default.
Can you take over an existing application?
Often, and we would review it first and say honestly whether extending or replacing is the better value.
Do you provide ongoing support?
Yes, and it is optional rather than a condition, since the handover is designed to make you capable of running it.
Who can access the production system?
Only who you authorise. Our access can be removed entirely at handover if you prefer.
What does a web application cost?
Scope and integration count determine it, quoted after the scoping review.
Glossary of terms
Web application terms in plain language.
- Access control
- The rules deciding which users can see and do what within the system.
- Rate limiting
- Capping how often a user or address can call a feature, which protects cost and availability.
- Graceful degradation
- The application staying useful when one component is unavailable.
- Custom software
- A system built for your process, as opposed to a configured off the shelf product.
- Handover
- Transferring code, infrastructure and documentation so another team could maintain it.
- Abuse protection
- Measures preventing a public feature being used at scale for unintended purposes.
Related services in AI Development
Talk to us about AI web applications
Describe the process your current software cannot handle. That gap is what decides whether custom is justified.
Start your project