Pinaque Technologies

Service

Application Engineering & Modernisation

Software you can run, maintain and own.

The problem

If this sounds like you

  • “Only one or two people understand this application, and they are afraid to change it.”
  • “Every change breaks something else.”
  • “The supplier has gone and we are left with the code.”
  • “We have a product idea, but no clear scope or estimate.”

What we do

We build new software and make old software safe to change.

You own what we build: the code, the documents and the decisions behind them. We write it so that your team, or another supplier, can pick it up without us.

Security is part of the design from the first day, not a check at the end.

There are two ways to begin. If you have an application that worries you, start with a health check. If you have an idea that needs shape, start with a discovery sprint.

What it covers

From a new build to the care of an old one.

  • Web and mobile apps

    Designed, built and handed over with the documents your team needs to run them.

  • Product builds

    From an agreed first version to later phases, with the scope written down at each step.

  • Application health checks

    An honest read of architecture, code, security and maintainability.

  • Clean-up

    Removing what is dead, fixing what is fragile, documenting what is left.

  • Modernisation

    Bringing an old application to a state where it can be changed safely again.

  • Maintenance

    Keeping a running application patched, supported and understood.

Three aids we use when modernising

These are ways of working, not products.

  • Understanding an old codebase before changing it

    We map what the code does, what depends on what, and where the risk sits, so nobody changes it blind.

  • Generating tests so changes are safe

    We put tests around the current behaviour first. Then a change that breaks something is caught before your users find it.

  • Moving an ageing application to a maintainable platform in stages

    One part at a time, with the old and new running side by side, so the business never waits on a single big switch-over.

Before we start

What must be true first

If these are not in place, this may not be the right time. We would rather say so on the first call.

  • We can see the source code, and speak to someone who knows the application’s history.
  • The application has a business owner who can say what matters and what does not.
  • For a product idea, there is a real user we can talk to. Without one, a discovery sprint is guesswork.
  • The decision is still open. If a rebuild is already chosen and funded, a health check adds little. Tell us, and we will scope the build instead.

Matching entry offer

Application Health Check

1–2 weeks, fixed scope

You get: Architecture, code, security and maintainability findings, and a fix backlog. Quoted after the first call. The written outputs are yours.

How the entry offers work

Matching entry offer

Product Discovery Sprint

2–3 weeks, fixed scope

You get: Scope, user journeys, the boundaries of a first version, a phased plan and an estimate. Quoted after the first call. The written outputs are yours.

How the entry offers work

Talk it through with someone who has run it.

Thirty minutes. We will tell you plainly whether this is the right first step.