We Don’t Outsource the Product

Domain-owned engineering, disciplined delivery, and a team you can trust

At Ishikawa, we run the group on a simple principle:

We centralise and outsource the undifferentiated, and we keep the core close.

For a software product company, the “core” is not vague. It is product ownership and engineering judgment.

We are not trying to maximise story points. We are trying to make mature software products better over time, reliably and safely, with a long-term quality bar.

What we centralise vs what we keep close

Across the group, plenty of functions benefit from centralisation or specialist suppliers: repeatable processes, standardisable operations, routine compliance work.

Engineering is different. We draw a clear line. We do not outsource product ownership. We do not outsource core engineering judgment. We do centralise repeatable engineering services internally where it creates leverage without losing accountability.

That distinction matters. We are not saying everything must sit in one team forever. We are saying the product improves fastest when domain context, tacit knowledge, ownership, and decision-making stay inside the business.

A quick Ishikawa term: “Genba”

In Ishikawa, each operating company is a Genba. It is the place where the real work happens. Genbas own their customers, their product outcomes, and their day-to-day decisions.

We build shared capabilities at group level, but we protect Genba-level ownership because that is where domain expertise compounds.

Kaizen Nexus: leverage without losing accountability

Where we centralise, we centralise inside Ishikawa.

Kaizen Nexus exists to provide shared services that are repeatable and can be delivered to a consistently high standard, with clear service boundaries and response expectations so

Genbas can rely on consistent support without handoffs turning into politics.

In engineering terms, Kaizen Nexus can provide maintenance support, break-fix capacity, and coordination of cross-cutting R&D. It is leverage, not abdication.

Why we care so much about domain-owned engineering

The companies we acquire tend to be mature, mission-critical SaaS products. Their customers rely on them for real operations. In that world, the work is not “implement the spec”.

The work is careful change management in a system with real users, real history, and real constraints:

• Safe migrations and versioning when you cannot stop the world and you cannot break yesterday’s data

• Regression prevention: test strategy that covers calculations, exports, reports, and the weird cases you only see in production

• Release hygiene: feature flags, rollback paths, monitoring, and incident response that engineers actually trust

• Performance and correctness together, especially where reporting queries and exports meet large datasets

• Paying down complexity in slices so quality compounds instead of decaying

We have found this becomes dramatically easier when engineers have stable ownership and can build tacit knowledge and familairity with the users, rather than operating at arm’s length from the customer and the business.

Why mature SaaS is an interesting engineering problem

Some people hear “mature SaaS” and imagine only maintenance. In practice, this is where engineering matters most.

You inherit real users, real data, and real constraints. You get to modernise carefully, improve reliability and observability, simplify complex workflows, and ship changes that customers feel immediately. The challenge is not novelty. The challenge is craftsmanship, correctness, and compounding quality.

And there is another part that matters: we are bringing fresh investment specifically to fund innovation that delivers real business value. Not “AI for the press release”, not churn-heavy rewrites, and not novelty features that nobody adopts. Practical innovation that saves time, reduces errors, improves cashflow and compliance, and makes the product meaningfully better for the people who run businesses on it.

AI: leverage for teams, and transformation for products

We are not building Ishikawa as “financial engineering with better vibes”. The product has to stay relevant, not just cash-flowing, and AI is changing the baseline.

We use AI to remove friction in engineering and operations: faster implementation scaffolding, better test coverage, clearer documentation, quicker debugging, and less repetitive work. Used well, AI is a compounding advantage for teams with good judgment.

We are rebuilding workflows around AI where it genuinely helps customers, especially in document-heavy, exception-driven processes like onboarding, bookkeeping ops, payroll inputs, support triage, renewals, and billing. The goal is measurable outcomes: time saved, fewer errors, faster cycle times, and better customer experience.

A key point for us is that AI does not replace domain ownership or tacit knowledge. It increases its value. The hard part is not generating output. It is knowing what “correct” means in the customer’s world, handling edge cases safely, and shipping changes without breaking trust. That is why we keep product ownership and engineering inside the business.

We are also investing in the foundations that make this work in practice: CI/CD, observability, and platform hygiene so AI-powered workflows can ship safely.

How we operate day to day

We care about outcomes: predictable shipping, high confidence changes, and product quality that compounds instead of decaying. To make that real, we run with a few practical commitments.

1. Clear ownership. You know what you own and what “good” looks like.

2. Few priorities at once. We limit work in progress so things actually finish.

3. Short cycles. We plan deliberately, ship in small increments, and learn quickly.

4. Definition of done includes quality. Tests, monitoring, and release readiness are part of the job, not an afterthought.

5. Telemetry matters. We use real usage data and support signals to steer priorities.

6. Quality is scheduled work. Reliability, tech debt, and “paper-cut” fixes are planned, not squeezed in after hours.

   
   

I call this disciplined delivery.

Big Red Cloud Group: re-integrating ownership

At Big Red Cloud Group, development had been delivered through a distributed external model across multiple suppliers and regions.

We inherited talented people and hard-earned knowledge. The issue was the operating model. When engineering is far from the domain and thin on ownership, quality becomes accidental and improvement is hard to compound.

Post-acquisition, we have been re-integrating engineering and product ownership because it matches how we want to run mature product businesses:

1. Smaller, stable teams with clear ownership boundaries

2. A roadmap that engineers can actually believe in, including what we are not doing

3. Fewer initiatives in flight so work finishes

4. Explicit space for quality, reliability, and “paper-cut” improvements

5. A bias toward shipping and maintaining, not thrashing

   
   

What it is like to be an engineer here

We are deliberately building an environment where engineers can do deep work and have a life:

• 100% remote

• Flexible time, where outcomes matter, not performative online presence

• Small teams with real autonomy and ownership

• Clear product vision and roadmap to avoid chaos and unshipped features

If you like craft, ownership, and shipping work you are proud of, you will probably feel at home.

Who you will work with: our hiring bar

Engineers do not just choose a company. They choose their colleagues.

We take hiring seriously because trust in the team is a massive quality-of-life factor. We assess for character and coding skill, and we include a structured cognitive assessment (including CCAT) as one signal among several. Not for prestige, but so engineers can trust the talent density of the team.

CCAT is one input, not a verdict. We combine it with real coding assessment and structured evaluation of how people show up: curiosity, reliability, humility, and collaboration.

We also recognise different backgrounds and learning styles, and we use structured assessment to reduce bias, not introduce it.

One signal we watch

Culture claims are cheap, so we prefer signals. Since the acquisition, Big Red Cloud’s Glassdoor score increased from 3.2 to 4.6.

Scores move slowly and imperfectly, but the direction matters. We treat it as a signal of clarity, stability, and respect for deep work starting to compound.

If this approach resonates

If you want to build and improve mature, mission-critical SaaS with clear ownership, disciplined delivery, low organisational noise, and colleagues you trust, we should talk.

At the time of writing, we're looking for fullstack .net engineers. Bonus points for ERP experience. Apply here.