Independent build & consulting work · Remote, on AU/US hours
Operations platforms · Real-time dashboards · Integrations & SSO · Migrations · Automation
That isn't a growth claim. It's what AI-assisted delivery does to a schedule when a senior engineer is holding the review. The model takes the scaffolding, the transformation grunt work, and the first draft of the tests. I keep the architecture, the data model, the security boundaries, and the judgment about what not to build at all. Twelve years of production systems across a national grid operator, a government audit commission, and remote teams in Australia and the US is what sits between that and vibe coding.
function engagement(problem) {
const real = traceToConstraint(problem);
// the brief is rarely the problem
return build({
scope: 'smallest thing that holds',
owner: 'your team, not me',
handover: 'still running in year three'
}, real);
}The honest answer is that AI writes a significant share of the code. That's also the answer that should make you cautious, because the same tools are producing a great deal of software that demos beautifully in week one and becomes somebody's problem in month three. The tool isn't the variable. Who is holding the review is. I work in Codex and Claude Code daily, with n8n for the workflow automation around them.
Vibe coding
Twelve years of production systems, with AI in the loop
In calendar terms: scaffolding, wiring, transformation code, first-draft tests and documentation used to eat weeks and now take days. The parts that decide whether the system survives take exactly as long as they always did. The data model, the boundaries, what happens when it fails. That is the part you are actually paying for. Net effect, work that would once have been quoted in quarters gets quoted in weeks, against the same review bar and the same handover.
Where I let it drive
Where I don't
How I keep it honest
In practice
At NGCP I use n8n, Codex, and Claude Code to take repetitive process work out of the delivery loop, the kind of steps too small to staff and too frequent to keep doing by hand, while keeping approval points human where the outcome matters. ROOC was built this way end to end, and so was the career game further down this page: AI accelerating the parts I'd already decided, with me holding the design and the review. The bill for that speed shows up as more of your budget spent on the decisions and less on the typing.
Five things I get hired for. Each one is a problem I've solved more than once, in more than one industry. The case studies further down are the receipts.
A process your business depends on is running on a shared sheet, a chat thread, and two people's memory. I turn it into software without turning it into bureaucracy.
You need this when
What you get
Most dashboards fail quietly: the numbers go stale, somebody notices once, and the team drifts back to the raw feed. I treat freshness as an acceptance criterion rather than a performance target.
You need this when
What you get
Systems that won't talk, and a login screen for every one of them. The fix has to work without a rewrite, because the apps are live and owned by people with their own schedules.
You need this when
What you get
The database everyone agrees should move and nobody wants to be the one who moves it. What unblocks it isn't the transform. It's being able to prove the new system matches the old one before anybody commits.
You need this when
What you get
The steps that are too small to staff and too frequent to keep doing by hand. I automate those, and keep a human at the points where being wrong is expensive.
You need this when
What you get
Three ways in, depending on how well-defined the problem already is. All of them start with the same conversation, and none of them start with a proposal I wrote before we had it.
1–2 weeks · fixed scope
For when everyone agrees something is wrong, but not on what.
I sit with the people doing the work, trace the process end to end, and come back with a written finding: what the binding constraint actually is, the realistic options, what each would cost you in time and risk, and what I'd do. Yours to keep and hand to anyone, including a different developer.
Typically 4–12 weeks
For when the problem is clear enough to start and the system doesn't exist yet.
Scoped delivery of a working system: something real in front of your users in the first few weeks rather than at the end, a weekly demo against the actual workflow, and a hardening pass before handover: tests around the rules that matter, a deployment your team can run, and documentation written for whoever inherits it.
Ongoing · part- or full-time
For when you have more work than senior capacity to review it.
I join your team as a senior developer: delivery, code review, architecture decisions, and bringing the rest of the team along. The right shape when there's an area of the system only one person understands, or a backlog that's really a reviewing bottleneck.
The same five systems the services above are built on, written up the way I'd talk you through them: what was broken, what the real constraint turned out to be, and what I built once I knew the difference. No logos wall. The detail is the point.
Side project · Live
The problem
A game guild was running loot auctions, member rosters, and reward payouts out of chat threads and a shared spreadsheet. Every contested item turned into an argument nobody could settle, because there was no record of who changed what, or which rule was in force when the change happened.
The real constraint
It looked like a tracking problem. It was a trust problem. A tool that let an administrator quietly edit history would have been abandoned inside a week, so the audit trail wasn't a feature to add later. It was the thing the whole design had to be built around.
What I built
Auction runs that carry their rules from the moment they open and move through a fixed lifecycle (open, awaiting result, finalized), so an assignment stops being editable once it's settled. Around that: a roster with a capacity, a reward catalog tied to rank bands, role-based access from Super Admin down, and an append-only history of every meaningful change. On Cloudflare Workers, so there's no server for a volunteer admin to keep alive.
Outcome Contested assignments now get settled by pointing at the log instead of re-arguing them. Onboarding an officer is one role change rather than a conversation about who to trust with the spreadsheet.
Energy · National Grid Corporation of the Philippines
The problem
Operators were reconciling SCADA telemetry against the electricity market's five-minute settlement intervals by hand, reading raw feeds in one place, market figures in another, and holding the comparison in their heads while decisions were already due.
The real constraint
The data arrives on the market's clock, not the user's. A dashboard that's even a minute stale is worse than no dashboard, because people quietly stop trusting it and go back to the raw feed. Freshness wasn't a performance target. It was the acceptance criterion.
What I built
I led Project Sentinel and the 5-Minute Real-Time Dashboard: an aggregation layer that pulls SCADA and market data onto the settlement interval, and a front end that shows the current interval, its inputs, and how stale each number is, so an operator can tell at a glance whether to trust what they're looking at.
Outcome The manual cross-check disappeared from the operators' interval routine, and the dashboard became the reference both operations and market interface teams worked from.
Enterprise identity · NGCP
The problem
Years of internal micro-apps had accumulated, each with its own login screen and its own user table. Onboarding somebody meant touching every app; offboarding meant remembering to. Nobody could answer the audit question: who still has access to what?
The real constraint
A clean rewrite was never on the table. The apps were live, owned by different teams, and written across different stacks and eras. So the design had to let apps migrate one at a time, on their owner's schedule, with the old login still working the day before they switched.
What I built
A central sign-on service the apps could adopt incrementally, plus the Market Data Interchange that moved data between systems on the same identity model, so access questions and data-flow questions finally had one answer each instead of a dozen.
Outcome Access became a single revocable thing per person rather than a scavenger hunt across apps, and new internal tools started from an identity layer instead of building another login.
Data platform · Legacy modernization
The problem
Core business data sat in an aging Oracle estate carrying licence cost and a shrinking pool of people who understood it. Everyone agreed it should move. Nobody wanted to be the one who moved it.
The real constraint
The business doesn't pause while you migrate, and a cutover that silently loses a day of records is a failed cutover even if every row copied. The hard requirement wasn't the transform. It was being able to prove the new database matched the old one before anybody committed to it.
What I built
A migration pipeline that transformed legacy Oracle structures into a PostgreSQL model and reconciled the result on counts, keys, and business totals, so the two systems could run side by side and disagreements surfaced as findings instead of as production incidents after the switch.
Outcome The migration became a reviewable, repeatable process rather than a single high-stakes weekend, which is what made it safe enough to actually do.
Investigation software · Comtrac, via GoTeam
The problem
An investigation management platform where evidence handling has to stand up to scrutiny later: who saw what, when, and what changed. Casework is written slowly and carefully, but read constantly, from many angles, by people who need an answer now.
The real constraint
Reads and writes had almost nothing in common. Writes needed to be strict, validated, and permanently recorded; reads needed to be fast and shaped around whatever question an investigator was asking. Forcing both through one model was making each of them worse.
What I built
I worked on the platform's move toward a CQRS architecture, separating the write path from purpose-built read models, and delivered features against it in Vue 3 and .NET, alongside the ongoing maintenance the product needed to stay stable for live investigations.
Outcome Query-shaped features stopped forcing changes to the write model, so new views could be added without putting the integrity of existing case records at risk.
The pattern under every case study above, and what the first weeks of working together look like. It isn't a methodology I'm selling. It's what stops me building the wrong thing well, on your budget.
01
A brief is a symptom somebody already interpreted for me. I go and see how the work actually moves through your business, including the workaround your people invented and stopped mentioning, which is usually where the real requirement is hiding.
02
Most problems have one constraint doing the damage and a crowd of symptoms around it. Trust, freshness, an unmovable legacy system, a schedule nobody controls. Naming it changes what's worth paying for, and rules out most of the obvious answers, usually including the expensive one you were about to buy.
03
Something real, in front of the people doing the job, early. Not a prototype I throw away, but the actual first version, narrow on purpose. Being wrong in week two costs a conversation. Being wrong at launch costs the project.
04
A system only I can operate isn't finished, it's a subscription to me. Clear boundaries, tests around the business rules that actually matter, repeatable deployment, and enough logging that your next developer can answer "what happened?" without my number.
Twelve years across energy, government, healthcare, proptech, and investigation software, in-house and on remote teams in Australia and the US. Every service above traces back to a stop on this list, which is the only reason I'll put a number on what one takes.
Same nine roles, built as a side-scroller with no libraries, just CSS and
requestAnimationFrame.
Walk with ← / → or A / D, jump with W / Space, or use the on-screen controls. Tap a building to walk straight to it. Visit every building to collect the stars, bump the ? blocks for coins, and reach the flag to finish.
Grouped by how well I actually know them, not by everything I've ever touched, so you can tell the difference between "I'll be productive on day one" and "I'd be learning on your budget." I'll say which one it is before you hire me, not after.
Current stack. Productive from the first hour, no ramp-up on your clock.
Delivered and maintained real systems in these. A short warm-up and I'm back at speed, which is fine for a build and worth knowing up front.
Used for real work, but I'd want a ramp-up before owning something critical of yours, or I'd tell you to hire a specialist.
John Berlyn Isip, or JB. Senior full-stack developer based in the Philippines, twelve years into building the unglamorous systems businesses actually run on: internal tools, APIs, dashboards, integrations, and the automation that removes work nobody should be doing by hand.
In-house at a national grid operator and a government audit commission, and on remote product teams in Australia and the US. That mix matters more than it sounds: the in-house years taught me what happens to a system three years after the consultant leaves, and the remote years taught me to be useful to a team I'm not sitting next to.
Outside client work I serve as a youth pastor and consult for a local organization. Both keep me practised at the part of this job that isn't code: listening properly before proposing anything, and telling people what they need to hear rather than what closes the conversation faster.
Community
Come to Jesus Church Montalban
facebook.com/CtjMontalbanLeadership
GFMIC, Inc.
gfmic.phNot with a spec. Tell me what the day-to-day actually looks like: the spreadsheet, the hand-off nobody wants to own, the system everyone's afraid to touch. You'll get an honest read on whether it's worth building, whether I'm the right person for it, and roughly what it would take.
What helps in a first message
A few paragraphs is plenty. If it's not a fit, I'll say so and point you at what is.
GitHub
github.com/jaybeemind