Engineering for organizations.
From the first conversation to a running system: requirements, design, build, testing, deployment and handover. Business automation and systems integration are the specialism.
Custom software development
Software specified, designed, built, tested and deployed to a written set of requirements: web applications, back-office systems, services and the integrations between them.
Typical situations
- A process or product the business runs that no packaged software fits.
- A system that has to be replaced because the vendor is gone or the spreadsheet cannot grow.
- A product idea that needs a working first version, built to be maintained.
What gets built
The full system: data model, application, integrations, deployment, documentation. Technology is chosen for the problem and the people who will run it; recent work is built on TypeScript, Next.js and PostgreSQL.
What you hold at handover
A working system accepted against the proposal's criteria, deployed, with its documentation, access and knowledge transfer completed.
Business process automation
A process that runs on email, spreadsheets and memory, rebuilt as software with states, rules, owners and an audit trail.
Typical situations
- Approvals, onboarding, quoting or compliance records tracked by hand.
- Work that depends on one person remembering the next step.
- Exceptions that nobody sees until a customer calls.
What gets built
The process as a system: each step with its owner and deadline, validation at entry, automatic routing, notifications, and exceptions sent to a person with the context attached.
What you hold at handover
The process running in a system, with the rules written down and a record of every case.
Workflow automation
Recurring steps between tools (intake, routing, notification, scheduled work) automated with monitoring, retries and a record of what ran.
Typical situations
- A nightly export someone runs by hand.
- Data that has to be moved from a form, an inbox or a file into a system.
- Notifications and reminders sent from memory.
What gets built
Scheduled and event-driven jobs with logging, retries and alerts, deployed where they can be seen; where an automation platform is the right tool it is used with the same discipline.
What you hold at handover
Jobs you can see running, with alerts when something fails and a runbook for when it does.
API and systems integration
Two or more systems connected through their APIs or files, with a defined source of truth for each field and a log of every record that moved.
Typical situations
- Orders, customers or invoices re-keyed between systems.
- Three tools holding three versions of the same record.
- A vendor API that has to be connected to a system that was never built for it.
What gets built
Integration services that map, validate and move data on a schedule or on events, with idempotent writes, retries and a reconciliation report; webhooks where the systems offer them.
What you hold at handover
A synchronisation you can audit: what moved, when, and what did not.
Custom web applications and internal tools
Browser applications for staff or customers: accounts and roles, forms with validation, tables, documents and reports, built around the real workflow.
Typical situations
- A shared spreadsheet that has become a system of record.
- A customer portal for documents, requests or status that nothing off the shelf provides.
- An operations console that has to show several systems at once.
What gets built
A web application with authentication, roles, validated forms, search, history and exports, hosted and documented; accessible by default and usable on a phone.
What you hold at handover
An application your team can run on, with its hosting, documentation and access handed over.
How the work is built.
Requirements in writing before code
Discovery ends in a written understanding of the workflow and the systems; the proposal turns it into deliverables and acceptance criteria both sides can point to.
A source of truth for every piece of data
Where two systems hold the same record, the design names which one is authoritative for each field, and the integration moves data once, idempotently, with a log.
Working software at agreed points
Progress is shown as running software on a staging environment, not as status reports; a change to scope is written down and priced before it is built.
Tests and acceptance criteria that match
Automated tests cover the rules the proposal names; the acceptance walkthrough runs the same workflows with the client's own data.
Deployed, observable, recoverable
Systems ship with logging, alerts for the failures that matter, retries where an outside system can be slow, and a rollback path.
Handover you can run on
Documentation, a runbook, accounts, credentials and the knowledge-transfer sessions named in the proposal, with ownership and access settled in writing.
Who we work with.
Businesses
Companies commissioning software for their own operations: a problem, a budget, a person who owns the outcome.
Agencies, software companies and consultancies
Firms that keep the client relationship and hand Primanza the whole project under the scope they agree with their client.
White-label partners
Partners whose delivery is presented under their own brand, where that is agreed in writing.
Technology
Chosen per project for the problem and for whoever will run the system afterwards. Recent work is built on TypeScript, Next.js, React and PostgreSQL, with Stripe where billing is part of the system and OpenAI where language is; the same stack is a sensible default for most web applications and integrations, and it is not forced on a project that needs something else.
Questions a project starts with.
How does a project start?
You write through the contact form or to hello@primanza.com with the problem, the systems involved and what a good outcome looks like. We talk it through in a discovery conversation, and the proposal puts deliverables, acceptance criteria, timeline and terms in writing. A reply comes within two business days, Monday to Friday.
What does the proposal contain?
Deliverables, assumptions, dependencies, acceptance criteria, timeline and commercial terms, written so both sides can point to them during the project and at acceptance.
Can you work with the systems we already have?
Yes. Most projects connect to something that already exists: an ERP, a CRM, an accounting system, a spreadsheet, a vendor's API. Discovery maps those systems first, and the design names which one is the source of truth for each piece of data.
How long will it take, and what will it cost?
Both are set in the proposal after discovery, because both depend on the scope. There is no standard turnaround and no published rate; the form asks for an optional budget range and timeline so the first conversation starts from your constraints.
Who owns the code and the data?
Ownership, licences and access are agreed in the proposal, in writing, before work begins. Handover delivers the documentation, access and knowledge transfer that the proposal names.
What happens after launch?
Launch and handover complete the project as scoped. Ongoing support — its scope, duration and cost — is agreed per project in the proposal; there is no standing package.
Do you work with agencies and consultancies?
Yes. An agency, software company or consultancy keeps its client relationship and hands Primanza the whole project under the agreed scope. White-label delivery is possible where it is agreed in writing.
How is security handled?
By building it in: role-based access, audit logs, encrypted backups and written data-handling terms. No independent penetration test of Primanza's work has been completed yet and no certification is held; the security page says so.
Who will I be working with?
Primanza is run by its founder, who holds the discovery conversation, writes the proposal, builds the system and hands it over. The Company page names him.
Discuss your project.
Describe the problem, the systems involved and what a good outcome looks like. The discovery conversation starts from there, and the proposal puts the scope in writing.
You write
Through the form or to hello@primanza.com: the problem, the systems involved, what a good outcome looks like, and any constraints you already know.
We talk
A discovery conversation about the workflow as it runs today and the outcome you need. A reply comes within two business days, Monday to Friday.
The proposal
Deliverables, assumptions, dependencies, acceptance criteria, timeline and commercial terms, in writing, for you to accept or change.