Provider change
OpenAI this quarter, Anthropic next, a Hugging Face endpoint for a private model. The product has to call an interface, not a hard-coded SDK in every screen.
AI & Developer Tools
The public stack is not mysterious. Labs train models. Clouds host them. OpenAI, Anthropic, Hugging Face, Google, AWS, Microsoft, Meta, NVIDIA: that is the market a product has to live in. GitHub and Vercel are how a lot of that software actually ships. Most companies in this industry are not training a foundation model. They are wiring one into something a team can log into on Monday.
A demo in a notebook is not a product. A product has accounts, roles, a bill or a cap, logs you can read when something hallucinates, and a way to take the code when you leave the vendor. In Nigeria that also means NITDA’s AI guidance, NCAIR as the public research centre, NDPC on personal data in prompts, and NCC where the product rides a telco channel. If the only artefact is a prompt in someone else’s UI, you do not have software. You have a subscription.
We build that layer: the app, the API, the keys in your environment, the export path. We do not train a frontier model. We do not keep the repository. You own the code; the model vendor owns the weights.
Who this is for
- Teams that need a model behind a product with auth, not a ChatGPT tab.
- Developer tools and generators that have to emit real code — including an export — not a screenshot of a happy path.
- Internal tools where usage must be capped, logged, and recoverable when the provider is down.
In this sector
Models, clouds, and the product in front.
A model behind a door
Sign-in, roles, and a route that calls a provider. The model is a dependency, not the product.
Clouds you already use
AWS, Google, Microsoft — the same places the rest of the stack lives. We do not invent a new cloud to host a prompt.
Tools a team can ship with
Generators, agents, internal copilots: they still need logs, limits, and a repo someone else can take over.
Keys and exit
Provider keys sit in your environment. The application code is ordinary. If you cancel us, you still have both.
Areas covered
We build the software around the model. Typical work includes:
01
Product and workspace
The surface people use every day: projects, conversations, generations, settings. Not a single demo prompt with no history.
02
Model as a dependency
Adapters so you can change provider or model without rewriting the product. Failures, retries, and timeouts treated as normal, not as a surprise at launch.
03
Auth, usage, and cost
Who can call the model, how often, and what it costs. Caps and logs so finance is not discovering the bill in production.
04
Export and handover
If the product generates code or artefacts, the customer can take them. The repository, keys, and hosting sit in your name. Djuix.io is the case in this sector: generated Django you can export, not a locked playground.
What the software has to survive
An AI product is not finished when the happy prompt works. It has to survive a key leak, a model swap, a spike in tokens, and a customer who wants the files.
Secrets and environments
Keys do not live in the repo. Staging and production do not share them. A leaked screenshot of an admin panel should not be enough to drain the budget.
Data that should not leave
Prompts can contain customer data. NDPC sits on that, NITDA on the digital service. You decide what is sent, what is stored, and what is logged. We implement that policy. We are not your DPO and we do not file your NDPC returns.
Cost and failure
Token bills spike. Providers 429. The product needs limits, queues, and a degraded mode that does not pretend the model is up.
Questions a technical buyer will ask
If you cannot answer these, you have a demo. We design so you can.
- 01
Whose keys sit in which environment?
- 02
Can you swap the model without rewriting the product?
- 03
What leaves the building when a prompt contains customer data?
- 04
Can the customer export the artefact and keep running?
- 05
What happens when the provider is down or the bill spikes overnight?
How we build it
We treat the model as infrastructure. The application is still an application.
Ordinary codebase
Auth, jobs, storage, and UI you can hire for. The model call is a module, not the architecture.
Environments that do not mix
Test keys and live keys are separate. We do not debug production with a founder’s personal token.
Limits by default
Rate limits, spend caps, and logs before the first public user. Cost is a product requirement.
Handover
Repo, keys, runbooks: rotate a key, switch a model, export a project. You own it.
- Your engineer sits in discovery if you have one — not after the first invoice from the provider.
- We do not ship a product that only exists inside a vendor playground.
- We do not keep provider keys after handover.
Where we stop
We build the product around the model. We do not pretend to be the lab or the cloud.
- We do not train or host a foundation model. We do not sell GPU time.
- We do not claim OpenAI, Anthropic, Google, AWS, Microsoft, Meta, NVIDIA, GitHub, or Vercel as clients. Those names define the stack.
- We do not hold a NITDA certificate, an NDPC filing, or an NCC licence. Those agencies define the environment. They are not a badge on this page.
- We do not keep the repository or production keys after handover.
The landscape
Nigerian agencies that write the rules, then the labs, clouds, and tools a product actually talks to. This is the stack — not a list of Emicraft clients, and not a claim that we hold those licences.
Regulators & agencies
Labs
Clouds
How it ships
Putting a model behind a product a team can own?
Bring the provider you are allowed to use and what the user actually has to take home. Djuix.io is the case in this sector — generated APIs you can export, not a locked demo.