Software Engineering
The system around the model still has to work.
Most of our work begins with an AI problem. Some of it turns out to be a software problem: an integration, an identity system, a backend never designed for what it now does. Northvian does that engineering too, when it supports the AI work.
01
What this work is
Software engineering at Northvian is the supporting capability. An AI system depends on the software around it: the application that holds it, the integrations that feed it, the identity system that tells it who is asking, and the delivery pipeline that gets a change to users without breaking anything. When that software is not up to it, the AI work stalls, and we would rather fix the foundation than build on it as it is.
The work covers application architecture, integrations, identity and access, quality practices, observability (being able to see what the system did and why, from logs, traces and metrics) and delivery. It is plain, senior engineering: the kind that decides where state lives, what happens when a dependency is down, and how a change reaches production on a Tuesday afternoon without a war room.
We take it on when it supports the AI mission: the backend your prototype needs, the integration your automation depends on, the authorization (the check of what this specific user may see and do) your product cannot ship without. We do not take on general software projects with no AI connection. There are good firms for that, and we would rather stay useful at the thing we do.
02
Is this you?
-
“Our AI feature is fine. The backend it sits on wasn't built for it, and every new capability takes longer than the last.”
-
“We need to connect the AI system to our CRM, our document store and our accounting software, and none of them has the API we hoped for.”
-
“Identity and access were done quickly. Now the AI system needs to know exactly who's asking, and we can't answer that.”
-
“Nothing is tested, deploys are by hand from one laptop, and we'd like to sleep.”
03
What we actually do
- 01
Find what the AI work needs from the software
The specific gaps, not a general modernization. You get a short list, in order.
- 02
Design the smallest change that closes them
An architecture note, an integration plan, an identity and authorization design. You get the reasoning, not just the diagram.
- 03
Build with the basics in from the first commit
Tests on the paths that matter, observability, and a repeatable deployment. You get software you can change safely.
- 04
Hand over
Documentation, a named owner, and a walk-through with your team. You get something you can run without us.
04
What we might tell you not to do
-
Don't rewrite the platform to add an AI feature
The feature needs a few specific things from the platform. Add those. A rewrite takes far longer than anyone plans for, and the feature is the reason you started.
-
Don't build the integration on screen scraping when an export or an API exists
However ugly the export is, it will still be there after the vendor changes the screen layout.
-
Don't let the AI system be the first thing with proper logging
If the application around it cannot be observed, every failure will be blamed on the model, and half of them won't be its fault.
-
Don't skip identity because it's internal
The AI system will read whatever the application lets it read. If the application cannot say who is asking, neither can the model.
05
What you receive
-
Architecture note
What changes, what stays, and why.
-
The software
In your repository, owned by you.
-
Tests and a delivery pipeline
Automated tests on the paths that matter, and a deployment that repeats and rolls back.
-
Observability
Logs, traces and metrics you can actually use when something goes wrong.
-
Documentation and handover
Enough for your team, or the next engineer, to pick it up.
06
How an engagement runs
- 01 Under 1 week
Scope
The gaps the AI work has exposed, and the smallest change that closes them.
- 02 2 to 8 weeks
Build
Depends on the gap: an integration sits at the low end, an identity system or a backend rework at the high end.
- 03 About 1 week
Hand over
Documentation, the walk-through, the owner named.
Formats
- Scoped inside an AI Product Development or AI Automation engagement, which is how most of this work arrives.
- A standalone fixed-scope piece when the gap is clear: an integration, an identity system, a delivery pipeline.
- Senior engineering time by the month, for a team that needs hands rather than a project.
Bands are typical for one gap. Several gaps, or systems with no API, extend them.
07
Technical and risk notes
What we look at
- Architecture and state: what is synchronous, where data lives, what blocks on what.
- Integration surfaces: APIs, webhooks, exports, and the vendors with nothing but a screen.
- Identity and authorization: who is asking, and whether every data path checks it.
- Test coverage on the paths that matter: authentication, data access, the tool layer.
- Deployment and rollback: repeatable, versioned, reversible in minutes.
- Observability: logs with correlation across requests, traces, metrics, and alerts that reach a person.
What can go wrong
- The integration has no API, and the vendor's export runs once a night.
- Authentication was generated and never reviewed.
- Deploys happen by hand from one laptop.
- No tests on the data paths, so every change is a gamble.
- Logs with no way to follow one request through the system, so nothing can be traced.
- The backend blocks on the model call, and one slow request stalls everything behind it.
08
Questions people ask
Do you take general software projects?
When they support the AI mission. If the work is the backend an AI product needs, the integration an automation depends on, or the identity system that lets an AI feature know who is asking, yes. A software project with no AI connection is better served by a firm that does that all day.
Can you work alongside our developers?
Yes, and it is usually the better arrangement. We take the pieces where senior judgment matters most, your team keeps ownership, and the handover is a conversation rather than a document.
Which languages and platforms do you work in?
The ones your system already uses, where that is sensible, and we say when a choice will cost you later. We are not tied to one stack and we do not resell any platform.
Will you maintain it afterwards?
Either we hand it to your team with documentation and a walk-through, or we look after it by the month. Decided at scope, not discovered after launch.
Bring the system around the model.
If the AI work is stuck on the software, that's a conversation we're glad to have.