Pamacore Labs

Engagements

The work, and how it actually goes

Sixteen engagements I take on regularly — what the situation usually looks like, how I'd approach it, and the part that tends to cause trouble. A few include the case for not doing the project at all, because that's sometimes the right answer.

These describe project types rather than specific clients. The patterns, constraints and failure modes come from a decade of enterprise architecture work; client engagements themselves stay confidential. On a call I can go considerably deeper on anything relevant to your situation.

Custom Software
SaaS and product teams with EU or multi-jurisdiction users· 6–10 weeks

Building the data-rights machinery a privacy regime actually requires

The situation

A product that collects personal data and was built before anyone had to think about it. The data sits in the main database, and also in application logs, analytics events, a support tool, an email platform, a spreadsheet somebody exported eighteen months ago, and backups nobody has inventoried. Then a deletion request arrives, or a prospect sends a security questionnaire, and the honest answer to “where does personal data live” turns out to be nobody’s job to know.

How I'd approach it

Discovery before building anything. Map where personal data genuinely resides — including where it has leaked to, which is almost always logs, analytics payloads and third-party processors rather than the tidy columns someone expected. Then build the mechanics: subject access export, deletion that reaches every store rather than just the primary table, consent capture that records what was agreed and when, retention rules enforced by a scheduled job instead of by a policy document, and an audit trail that can evidence what happened. Where deletion conflicts with a legitimate need to retain — financial records being the usual case — the answer is pseudonymisation, and which fields that covers is a decision for your counsel, not for me.

What usually bites

Backups are the genuinely hard problem. A deletion request runs headlong into immutable backup media, and the workable answer is normally documented rotation with deletion reapplied on restore — but that is a position your lawyer signs off, not one an engineer should be inventing. The other reliable surprise is free text. Users type personal data into support tickets, internal notes and description fields, and no schema-level mapping catches it.

What I'd cut first

A self-serve privacy dashboard for end users. Handle requests through a documented internal process first and automate intake once volume justifies it — the obligation is to respond properly within the window, not to respond through a portal.

When I'd tell you not to

If you don’t yet have a lawyer or DPO engaged, start there rather than with me. I build the mechanisms that carry out a legal position; I don’t determine what that position should be, and any technical supplier who offers to decide your lawful basis is selling something they can’t stand behind.

.NET 8AngularAzure SQLAzure FunctionsKey VaultAzure Monitor
Custom Software
FMCG distribution, wholesale, dealer networks· 10–14 weeks

A CRM for a distributor, because the off-the-shelf ones don't fit

The situation

The business runs on spreadsheets and an accounting export. Generic CRMs have been trialled and abandoned, usually for the same reason — they model a sales pipeline well and a dealer hierarchy badly. Territory rules, slab-based schemes, credit limits and channel pricing all end up back in Excel because the CRM couldn't express them.

How I'd approach it

.NET Core API with an Angular front end. The scheme and pricing engine is treated as the core domain and built first with real test coverage, because it is exactly what generic products get wrong and what the business will judge the system on. Role-based access reaching down to territory. Real-time stock visibility where reps need it. Accounting integration runs as a scheduled sync rather than a live dependency, so a failure there doesn't take the CRM down with it.

What usually bites

Scheme logic carries exceptions that live in the sales head's memory and surface one at a time during UAT. Getting them written down before build starts is most of the discovery work and worth being stubborn about. The second risk is adoption — reps who have tracked their own retailers in a personal spreadsheet for years do not hand that over readily, and that needs managing as a change problem, not a training one.

What I'd cut first

A native mobile app. A responsive build covers the field requirement well enough to learn what a mobile app would actually need to do.

.NET 8AngularEF CoreAzure SQLSignalRTally integrationAzure App Service
Custom Software
HVAC, installation, maintenance, field operations· 8–12 weeks

A field service app that works where there's no signal

The situation

Technicians work off paper job cards. Data reaches the office days later, sometimes illegibly, and dispatch decisions get made against a picture of the world that is already stale. Connectivity at actual sites ranges from patchy to nonexistent.

How I'd approach it

Offline-first as an architectural decision rather than a feature — a local store with a queued sync, and conflict resolution rules agreed with the business before any code is written, because those rules are a business decision engineers shouldn't be making alone. Photo capture with client-side compression, since site photos over a weak connection will otherwise sink the sync. Digital signature on completion, push notification on assignment, and a .NET Core API behind it all.

What usually bites

Adoption, more than architecture. If completing a job in the app takes more taps than the paper card, technicians keep using the card and fill the app in from the van at day's end — which produces worse data than paper did. Timing the workflow against the paper form in week one is not optional, and it usually forces a redesign of at least one screen.

What I'd cut first

Dispatch and route optimization. Get accurate job data flowing first; optimizing a schedule built on bad inputs is not worth much.

.NET 8Angular PWAIndexedDBAzure MapsAzure Notification HubsAzure Blob Storage

What drives the number

Why two similar projects quote differently

Four variables account for most of the difference. Understanding them is also how you reduce the number — several are things you control.

How many systems have to talk

One system in, one system out is straightforward. Each additional integration adds its own auth, its own failure modes, and its own vendor documentation of variable quality. This is the single biggest driver on most projects.

The state of the data

Clean, consistently structured source data makes a build predictable. Twelve years of inconsistent records, duplicate masters and undocumented columns turns a five-week project into an eight-week one — and that work happens whether or not it was scoped.

Which decisions are already made

If your team already agrees what an active customer is, or how a sync conflict resolves, the build starts immediately. If not, that agreement has to be reached first, and it needs a decision-maker rather than an engineer.

Who takes it over

Handing to an internal team who will maintain it is cheaper than building something that has to run untouched for two years. The latter needs more documentation, more defensive handling, and more thought about the failure modes nobody will be watching for.

I quote a fixed price after the mapping session, not before. An estimate given without seeing your systems is a guess with a margin baked in for being wrong, and you end up paying for that margin whether or not it was needed. Indicative starting points for each type of engagement are on the pricing page.

The engagement model

Four phases, no surprises

Same shape whether it's a three-week automation or a fourteen-week application build. Each phase has a defined output you can hold me to.

01

Map the actual problem

A working session on your process — where time goes, where errors creep in, what a fix is worth. You leave with a written opportunity map whether or not we go further.

→Opportunity map + rough effort estimate
02

Scope one narrow thing

One workflow, one measurable outcome, fixed price. Deliberately small — a scope you can judge in weeks beats a roadmap you have to take on faith.

→Fixed-price proposal + success metric agreed upfront
03

Build in the open

Weekly working software, not status decks. You see the real thing in your own environment and redirect while it's still cheap to redirect.

→Working system in production, deployed to your infra
04

Hand over properly

Documentation, a walkthrough with your team, and source in your repository. You are never locked into me — that constraint keeps the work honest.

→Docs, handover session, full source ownership

What you own at the end

Full source code in your own repository. Infrastructure in your own cloud account, under your billing. Documentation written for the next engineer, not for me. No proprietary runtime, no per-seat licence, no dependency on my continued involvement.

If you want ongoing support afterwards, that's a separate conversation — never a condition of the build.

Recognise your situation in one of these?

The mapping session is free and yields something useful even if we never work together.

Book a Free Consultation