Skip to main content
Wisely

IT Services

Software Development

Custom web applications, internal tooling and integrations, built to solve real business problems, not over-engineered for its own sake.

Get in touchAll IT Services services

Sometimes off-the-shelf software doesn't fit. When your business has a workflow, process or data requirement that no existing product handles well, custom development is the answer. We build focused, well-engineered software that solves the problem at hand.

What we build

We take on projects where custom software is genuinely the right answer, not just the most expensive one.

  • Internal tools and dashboards that connect your existing systems
  • Customer-facing web applications and portals
  • API integrations between enterprise systems
  • Workflow automation tools and bespoke process applications
  • Data processing pipelines and reporting systems

How we work

We follow a lean, iterative development process, delivering working software quickly and adjusting based on feedback.

  • Discovery sprint to define scope, requirements and architecture
  • Iterative delivery with working builds at each milestone
  • Code review, testing and documentation as standard
  • Handover to your team or transition to a support retainer

Before you build

Buy, configure, or build

Custom software is the right answer to some problems and an expensive answer to others. The cheapest project is the one you decide not to run, so this is the first conversation worth having.

Buy

A product already does this

If the requirement is a solved problem, such as accounting, payroll, CRM or file storage, an established product will be better tested, better supported and cheaper than anything built for you. Being one of thousands of customers funding a roadmap is an advantage rather than a compromise.

Configure

A platform gets you most of the way

A great many requirements that sound like custom software are configuration work on a platform you already pay for. Boards, forms, automations and integrations cover the bulk of most processes, and the remainder is where a small amount of custom code earns its cost.

Workflow Automation

Build

The process is the differentiator

Building is the right call when the workflow itself is what makes you competitive, when the real gap is integration between systems that will never talk to each other natively, or when per-seat licence costs on a product you have outgrown now exceed the cost of owning the thing outright.

Technology

One core stack, and two specialists

Four of these are really one thing: TypeScript end to end, with React and Next.js in front of it and Node behind. Python and .NET are here for the two jobs that genuinely call for something else. The reason to keep it coherent is not taste, it is that whoever maintains your application in five years should be looking at something they have seen before, rather than at the one project written in a language nobody else here uses.

Language, front to back

TypeScript

JavaScript with a type system, used on both sides of most builds. Types catch the class of error that otherwise reaches production down a path nobody thought to test, and they make a codebase legible to the next developer without a guided tour.

User interface

React

The interface layer for applications people sit in front of all day. The argument for it is ecosystem and staffing: accessible component libraries already exist rather than needing to be written, and hiring someone who knows it is straightforward.

Web application framework

Next.js

The framework around React that handles routing, rendering and the server side, so a customer-facing application is quick on first load instead of shipping a blank page and a spinner. It also settles a category of decisions that no project benefits from reopening.

Services and APIs

Node

Server-side JavaScript, which keeps one language across the application when the back end is largely moving data between systems. One set of types shared between client and server, and a smaller surface for a small team to maintain.

Data and automation

Python

Where the work is data processing, reporting pipelines, scripting against APIs, or anything touching analysis and machine learning. Chosen for the libraries rather than the syntax: the mature tooling for that category lives in Python.

Enterprise integration

.NET

For builds that sit inside a Microsoft estate, integrate with existing .NET services, or need to run on infrastructure your team already operates and understands. Ignoring what a business already runs is how the next unmaintainable system gets created.

If your problem would genuinely be better solved in something outside this list, the useful answer is to say so rather than to bend the work until it fits the stack.

Engineering standards

The standards we build to, by name

Quality in software is not entirely a matter of opinion. Security, accessibility and privacy each have a published standard behind them, so these are the ones the work is measured against, rather than an adjective.

Application security

OWASP ASVS 5.0

The Application Security Verification Standard sets out what a secure application has to do, across three levels of rigour, and version 5.0 arrived in May 2025. It works at design time, which is the point: security decided before the first line is written costs a fraction of the same security retrofitted once a test finds it missing. The OWASP Top 10:2025 sits underneath it as the list of risk categories to rule out.

Penetration Testing

Accessibility

WCAG 2.2 Level AA

Required by the New Zealand Government Web Accessibility Standard 1.2 since 17 March 2025. If you sell to the public sector, or expect to, this is a procurement gate rather than a preference, and retrofitting it into a finished interface costs considerably more than building to it.

Privacy and data residency

IPP 12 and APP 8

Where an application stores personal information is a legal question before it is a technical one. New Zealand's Privacy Act 2020 permits disclosure to a foreign entity only on reasonable grounds that comparable safeguards apply. Australia goes further: under section 16C you stay accountable for an overseas recipient even after taking reasonable steps. You can move the data offshore, you cannot move the responsibility for it.

Cloud

FAQ

Questions we are asked most

Who owns the code you write for us?
You do, and it is written into the agreement rather than left to the default, because the default is reversed on each side of the Tasman. Under section 21 of New Zealand's Copyright Act 1994, a person who commissions and pays for a computer program is the first owner of the copyright in it unless the contract says otherwise. Under Australia's Copyright Act 1968 the position flips: a contractor generally owns what they create unless the agreement assigns it to you in writing. Two businesses doing an identical deal in Auckland and Sydney can end up with opposite outcomes on the same paperwork, so ownership, repositories and deployment credentials are settled explicitly before work starts.
How do you estimate what it will cost?
A discovery phase first, priced separately and deliberately small, because an estimate produced before anyone has looked at your data and your integrations is a guess with a number attached. Discovery produces the scope, the architecture and a realistic range. The variables that move the number most are how many systems have to be integrated, how clean the data in them is, and how much of the process is genuinely unique rather than assumed to be. Fixed price suits a well-defined build; anything exploratory is honest about being time and materials.
Do you use AI to write our software?
Yes, as a tool, with the review discipline that makes it safe. This is worth being specific about, because the evidence is nuanced. DORA's 2025 research found that teams adopting AI assistants improved individual output and code quality while their delivery stability got worse, and the likely cause is volume: AI generates code faster than review and deployment practice can absorb it. The answer is not to avoid the tools, it is to keep the review, testing and release discipline that catches what they get wrong. Nothing reaches your environment because a machine produced it and it looked plausible.
Can you work with the systems we already have?
That is most of the work, in practice. Very little custom software is built into empty space. It usually has to read from an ERP, write to an accounting package, authenticate against Microsoft 365 and stay in step with a CRM that was configured by somebody who left. Integration is where projects fail quietly, so APIs, rate limits, data ownership and what happens when a dependency is unavailable are established during discovery rather than discovered during build. See Platform Integration
We have an old system nobody wants to touch. Can you replace it?
Usually, and rarely in one move. The risky approach to legacy modernisation is the full rewrite, where the old system runs untouched for a year or more while a replacement is built against a specification nobody can completely describe, because the real specification is the behaviour that has accumulated inside the software. The safer pattern, often called the strangler fig, is incremental: put an interface in front of the existing system, move one function at a time, and run both until the last one has migrated. It reads as slower on paper and it is far less likely to end in a rollback. The first task is usually establishing what the system genuinely does, which is not always what the documentation says or what the people using it believe.
What happens after it launches?
Software is not finished at launch, it is only in production. Dependencies need patching, security advisories arrive, the business changes and the first real users find the assumptions nobody questioned. You can take it in-house with the documentation and access above, or keep us on a support retainer with an agreed response time. What we would advise against is the middle option, where nobody owns it and the first person to notice a problem is a customer. See Managed IT

Build something that actually works

Tell us what you need and we'll tell you if custom development is the right answer.

Get in touchAll IT Services services