One Founder. One AI.
One Production System.

What is Intelletto.ai, and Why Does It Exist?

My first enterprise system wasn't built with a framework, a CI/CD pipeline, or a team of specialists. It was Pinnacle Software — a logistics ERP I wrote in C, deployed across clients in multiple countries, managing operations at a scale that, looking back, should have been impossible for one person to attempt. The fact that I also have dyslexia makes that chapter feel even more unlikely in hindsight. Reading is hard. Writing code — where the computer doesn't care about your spelling, only your logic — turned out to be a different thing entirely.

I didn't know then that I was building a mental model that would define the next twenty years of my career: technology is leverage. The right system, built well, multiplies human capability in ways that are genuinely hard to quantify until you've lived them.

Since Pinnacle, I've worked across most of the industries that matter — fintech, BPO, eCommerce, logistics, enterprise digital transformation — for companies ranging from scrappy startups to publicly listed institutions. And every single software development project, regardless of sector or scale, followed the same exhausting playbook. The business wants the solution yesterday. The development team — developers, QA engineers, PMs, product owners, infrastructure, security, compliance — already has more work than they can physically cope with. We paper over the gap with Agile methodologies, RAD tools, low-code platforms, code generators. We hire more people. We extend the timeline. We descope. We repeat.

I never stopped looking for a better way. What I found — eventually — is Claude Code. But I'll get to that.

An Industry Most People Underestimate

Before I explain what Intelletto.ai is and why it exists, I need to talk about an industry that most people outside of it genuinely don't understand: Business Process Outsourcing.

The global BPO market was valued at approximately $327 billion in 2025 and is projected to reach over $525 billion by 2030, growing at nearly 10% annually. It employs more than 25 million professionals worldwide. The Philippines alone accounts for 1.7 million BPO workers, representing one of the country's largest economic pillars. Over 72% of Fortune 500 companies outsource some portion of their operations. This is not a niche industry. It is one of the largest service ecosystems on the planet.

And a significant portion of that ecosystem runs on recruiting.

The volume of resumes that flows through large BPO operations is, frankly, staggering. A single mid-to-large BPO with continuous hiring cycles can process tens of thousands of candidate applications per month. Across the region's largest operators, we're talking hundreds of thousands of candidates per year, flowing across multiple client accounts and role types simultaneously. Each one of those candidates submitted a resume. Each one of those resumes had a human being on the other side of it, trying to make a fair assessment in the time they had available.

Here is the brutal arithmetic of that reality. Manually screening 300 resumes takes approximately 30 recruiter hours. Manual hiring averages $1,000–$4,700 per hire, largely due to recruiter time and overhead. Preparing a candidate shortlist costs an average of two additional hours — before a single interview has been scheduled. Multiply that across hundreds of open roles running simultaneously, and the recruiter capacity problem becomes obvious: it is structurally impossible to give every candidate the evaluation they deserve. Not because the recruiters aren't good at their jobs. Because the math simply doesn't work.

AI-powered resume screening can reduce initial screening time by up to 75%. Around 67% of hiring managers cite time savings as the single biggest advantage of AI in recruitment. These aren't projections from a vendor brochure — they're outcomes reported by organisations that have implemented even basic AI-assisted screening. Having worked inside large-scale BPO hiring operations, I saw impact of that order firsthand. Resume parsing and basic AI scoring didn't just save recruiter hours; it changed what recruiters were able to do with their time. Instead of triaging volume, they were doing actual talent evaluation.

But working that close to the problem gave me an uncomfortable feeling that has never left me: we were only scratching the surface. Basic parsing and keyword-based scoring is better than nothing. It is nowhere near what's possible. A resume is a compressed record of a career — years of decisions, pivots, promotions, lateral moves, skill accumulation, industry transitions. Keyword matching reads almost none of that. It sees the words. It misses the story.

The Platform

Intelletto.ai is an AI-native candidate intelligence platform. At its core, it does three things that incumbents cannot:

• Understands resumes semantically, not syntactically — extracting career trajectory, skills with proficiency depth, stability risk, role-switch signals, and seniority context from unstructured documents.
• Scores candidates against job requisitions using a rubric-based engine that produces explainable, auditable results — not black-box rankings.
• Operates across multi-tenant enterprise hierarchies — a full EOR → Customer → Employee tenancy model with role-based access control baked into the data layer, not bolted onto the application layer.

The technical stack is not timid. The backend is a FastAPI/Python platform with hundreds of documented endpoints, backed by Google Cloud SQL PostgreSQL (295 tables in production), Google Cloud Storage for document management, Google Document AI for parsing, and Gemini as the primary inference layer. Pipeline orchestration runs on Netflix Conductor with supervised workers, a watchdog, and per-stage advisory locks. Infrastructure is managed in Terraform across GCP's asia-southeast1 region.

What Claude Code Actually Is

Most people who haven't used Claude Code think it's a smarter autocomplete. It is not. Claude Code is Anthropic's agentic coding tool — a command-line interface that gives Claude direct, persistent access to your codebase, your terminal, your database connections, and your file system. It reads files. It writes files. It runs commands. It reasons across your entire project context and executes multi-step plans.

The distinction from tools like GitHub Copilot or even ChatGPT with code execution is architectural: Claude Code operates with agentic persistence. You don't paste a function in and wait for a suggestion. You describe an objective — "refactor the scoring engine to use typed protocol interfaces with per-stage artifact contracts" — and it navigates the codebase, identifies every relevant file, proposes and executes the changes, and verifies the result. It is the closest thing that currently exists to a senior engineer who is also infinitely patient and works at the speed of thought.

What makes it genuinely different for a solo founder-CTO is the compression of cognitive overhead. The mental tax of holding an entire system architecture in your head while writing implementation details is one of the core bottlenecks of solo technical work. Claude Code carries that architectural context. I can think at the strategy layer while it executes at the implementation layer.

That said — and this is critical — it is not magic. It requires disciplined collaboration. The difference between Claude Code as a force multiplier and Claude Code as a liability is almost entirely a function of how well you govern it.

The Good, the Bad, and the Genuinely Ugly

I want to be honest here, because most AI development content reads like a vendor brochure. The reality of building a production system with an AI coding partner involves real failures, real wasted time, and some genuinely alarming moments. It also involves breakthroughs that would have taken weeks by conventional means.

The Good

The moments that made me a believer were when Claude Code demonstrated something I can only describe as systems thinking. Early in the project, I needed to design a formal stage contract for the pipeline — a typed Python Protocol interface that every one of the 12 stages would implement, with strict input/output artifact typing, failure classification between TRANSIENT and PERMANENT errors, and per-stage observability hooks.

I described the architectural intent. Within a single session, we had a complete Protocol definition, a base class implementation, an orchestrator that respected stage independence, a telemetry event schema with a PostgreSQL migration, and stub implementations for all 12 stages that compiled and type-checked. That work represents at minimum a week of focused senior engineering effort. We did it in an afternoon.

Similarly, the multi-tenant RBAC model — a six-role hierarchy spanning Platform Admin, EOR Admin, EOR Recruiter, Customer Admin, Customer Recruiter, and Read-Only, with JWT payloads carrying dynamic tenant context — was architecturally defined and scaffolded across the FastAPI route layer in a session that would have taken a team of two engineers several days to produce at the same quality.

The Bad

Here is where I'll be uncomfortable with you. Early in the project, I discovered that my working codebase had only a single git commit — "Initial commit" — with nothing pushed to the remote repository. Every time I started a new Claude Code session, it was operating on whatever state existed on disk, with no reliable baseline. Because I hadn't established a disciplined push cadence, Claude Code was on more than one occasion working from incomplete context — and the results showed it.

This is entirely my failure, not the tool's. But it illustrates something important: Claude Code amplifies your engineering discipline as much as it amplifies your velocity. Poor git hygiene in a traditional team produces confusion. With an agentic AI tool, it produces sessions where you don't immediately realise the context is corrupted.

The fix was straightforward once identified — commit everything, push to GitHub, establish a cadence — but the time lost before that diagnosis was real and avoidable.

The Ugly

The ugliest moments were the P0 bug discoveries. After the pipeline had been running for some time, a systematic audit revealed three critical failures that had been silently executing incorrectly for every resume processed:

These bugs did not originate entirely from Claude Code — they were the product of iterative scaffolding where stubs got promoted to production without sufficient scrutiny. But they highlight the governance challenge: when an AI can generate plausible-looking code at high velocity, you need systematic verification processes that match that velocity. We implemented these — formal acceptance criteria, explicit stage contracts, structured audit protocols — but we should have established them earlier.

The lesson I took from this is that the CLAUDE.md governance file is not optional. It is as important as any other architectural document in the project.

Both of those P0 gates have since been resolved. Gate B now separates blocking from advisory schema errors and fails the pipeline on the former; Gate C verifies per-section fact coverage with a documented density floor. The third — the bucket dispatch / rubric persistence problem — has been substantially closed and is tracked in the public spec. Every fix landed with new regression tests in the suite. What turned the corner wasn't a single change but a pattern: every time we found a silent-failure mode, the next step was to make that mode loud — typed contracts, gate verdicts persisted to the database, audit packets that surface "evidence missing" instead of swallowing it. The system got more honest as it got more sophisticated, which is not the usual direction software travels.

The Final Product — A Detailed Look

Let me give you a complete picture of what actually exists in production, because I think the aggregate is more impressive than any individual component.

The Intelligence Pipeline

The 12-stage pipeline is the intellectual core of Intelletto. Each stage is an independent, typed module implementing a formal Python Protocol contract. The orchestrator is the only entity with authority to sequence stages, pass artifacts between them, handle failures, and emit telemetry. No stage has knowledge of any other stage — this isn't just good engineering hygiene, it's a deliberate architectural constraint that makes the system testable, observable, and safe to evolve.

Stage outputs include: raw text extraction, entity normalisation, career segment identification, skills extraction with 4-signal proficiency scoring (years of experience, recency decay, role frequency, seniority context), career trajectory classification with named flags — RAPID_ASCENT, STAGNATION, LATE_BLOOM, REGRESSION — stability risk scoring, role-switch risk modelling, and a final rubric-based scorecard with explainable component weights.

The Scoring Engine

The scoring engine is not a black box. Every candidate score is the product of a documented rubric formula with weighted components. Each component is individually auditable. The system produces a structured scorecard — not just a number — that includes skills match depth, experience alignment, trajectory assessment, and risk-adjusted candidacy signals.

The skills proficiency module operates on a 4-signal composite: raw years of exposure, recency decay (skills not exercised in recent roles score lower), role frequency (how consistently a skill appeared across positions), and seniority context (a skill claimed at executive level carries more weight than the same skill at entry level). This is the kind of nuance that keyword-matching systems cannot produce.

The GCS Pipeline Architecture

The Google Cloud Storage architecture uses path-based mode detection to route resume documents through the correct pipeline configuration. The RESUME-POOL/ prefix triggers Mode A (pool build). A job-code path segment triggers Mode B (pool activation). A direct upload with an attached job requisition triggers Mode C. The design keeps the pipeline stateless from a trigger perspective — intent is encoded in the file path, not in application state.

The Multi-Tenant Data Model

The database schema — 169 tables in production — is designed around a three-tier tenancy hierarchy: EOR at the top, Customer in the middle, Employee/Candidate at the leaf level. Every JWT payload carries eor_id unconditionally, with customer_id populated conditionally based on the authenticated role. Tenancy is enforced at the data layer, not just the application layer.

The Platform Interface

The frontend is built on a consistent design system with a permanent two-column navigation pattern: a dark icon strip paired with a white item panel. The JD Orchestrator provides a real-time interface for job descriptor management. A mission-control style monitoring dashboard provides per-stage observability into the pipeline telemetry system, with event-level visibility into every resume as it moves through all 12 stages.

Infrastructure and Deployment

The platform runs on Google Cloud Platform managed entirely through Terraform. Cloud SQL PostgreSQL in asia-southeast1. GCS buckets for resume intake, inference artifact storage, and Terraform state. The FastAPI application is containerised with Docker multi-stage builds for production efficiency. All infrastructure is version-controlled, reproducible, and auditable.

The Surfaces Built Since

The original cut of this piece talked about the pipeline, the scoring engine, the RBAC model, and the infrastructure. What follows is everything that's joined them in production since — because the rate at which a solo founder + AI can extend a platform is, I think, the part of this story that's easy to underestimate until you see it written out.

• Talent CRM (full): Talent Bank, Talent Pool, Talent Connect, Segments, Campaigns, Referrals, an Activity stream — the full relationship layer most ATS competitors leave as integration work.
• Career Site + apply experience: Branded multi-page career site with a recruiter-controlled builder. Mobile-first apply flow. Source tracking and attribution all the way from career-site visit to hired conversion.
• Interview Operations: Versioned interview plans, JD-anchored kits, structured rubrics, a conduct screen, anchoring-resistant feedback (peer scores hidden until I submit my own), a decision engine, and tokenised email approval for hiring managers who don't want to log in for a single click.
• Native interview scheduler: Slot proposal, candidate self-confirm, reminder dispatch, real Google Calendar adapter behind a feature flag. The OAuth verification path is documented in the governance file so nobody promises external-tenant calendar sync until verification is in flight.
• Hire & Onboard: Offer packages with versioned counter-offers, a generalised approval engine (one state machine for offers and interview decisions), document bundles, onboarding templates, manual-paste handoffs for the integrations we haven't built yet — and an explicit rule that we don't ship a half-built integration to look feature-complete.
• Recruiter Command Center: Mission control — ranking, candidate cards, longlist management. The AI surface area sits on top of this: a JD generator that takes a role brief and produces a complete JD with knockouts and interview questions, an AI candidate one-liner on every row, a red-flag detector that's bias-mitigation-prompted, a skill-gap explainer that turns a 70 into a recommendation with a ramp estimate.
• AI Bias Auditor: Gemini-driven review of generated JD copy, recruiter outreach, and scorecard prose. Flags spans, suggests rewrites, runs as advisory (it never blocks generation). Per-artefact apply vs acknowledge, because a scorecard rationale is immutable but a JD draft is not.
• Career Intelligence: Ten deterministic trajectory signals — velocity, scope progression, tenure stability, promotion cadence, sector continuity — feeding scoring modifiers. The signals are the kind of thing a senior recruiter reads instinctively in a resume; encoding them is what lets the platform produce scorecards a senior recruiter would actually sign.
• RBAC v1: A permission catalogue, role catalogue, per-tenant overrides, an admin UI. Eight months ago the platform had a hard-coded role enum; now it has a database-backed permission system with the override semantics a tenant admin would expect.
• Vendor cert linkage: A curated catalogue of more than two hundred industry-recognised certifications, mapped to skill footprints. When a recruiter ticks "AWS Certified Solutions Architect — Professional" on a JD, the system auto-fills the skills that credential actually represents. Less typing, fewer omissions, more honest scoring.

And then — this week — the part of the story I most want to write about.

The Auditor Validation System

Most AI hiring tools talk about audit. They mean: "the database has timestamps and you can export a CSV." What an actual auditor — an external regulator, a fairness firm, a tenant's compliance team — needs is something different. They need to be able to walk every claim on a candidate dashboard back to a source byte they can verify with their own eyes, and re-run the scoring on their own machine and confirm they get the same number. That bar is much higher than "we logged it."

The system that ships this is built out of pieces that were already in place — the SHA-stamped pipeline, the immutable scoring-input snapshot, the per-fact evidence spans, the rescore history — but it ties them together into a single artefact the auditor can hold in their hand. The deliverable is a fourteen-page Audit Report attached to every sealed scorecard.

Recruiters open the report inline in a browser tab. Auditors download a signed bundle — the PDF, the canonical machine-readable JSON, a detached cryptographic signature, a README — and run intelletto-verify packet.zip on their own machine. The verifier independently checks the signature against our published public key, recomputes every SHA in the chain, and re-runs the deterministic scoring routine on the immutable input snapshot. The output is a single line: VERIFIED, or VERIFICATION FAILED at a specific node. That's the bar. Not "trust our signature" — re-run the scoring yourself and see you get the same number.

The reason this matters in the context of this piece — and I want to be precise here — is that it is the strongest possible answer to the question every AI-assisted system has to eventually face: how do you know it wasn't fabricated? The Audit Report is the system producing its own evidence, on demand, in a form an auditor can verify without taking anyone's word for anything. Every architectural choice that came before — the per-fact source attribution, the immutable snapshot, the SHA-stamped chain, the gate framework, the rubric versioning — was building toward the moment when that report could be assembled without compromise. This week it can.

The work itself was a tight loop. A spec written in an afternoon. A four-phase plan. Subagent-driven execution where Claude Code did most of the wiring with me steering on the architectural calls — what does each audience profile redact, where does the signature go in the canonical JSON, which fields are pinned by the SHA and which are cover-sheet metadata. The first draft of the report PDF was thin — one page with empty placeholders — and the user feedback (very direct) was "this makes no sense to any human." That was correct. Rewriting the template to actually deliver against the spec section, rewiring the export endpoint to call the rich builder, and re-running the regression suite took another session. The final report is 14 pages of substantive content backed by a 71 KB canonical JSON. Whether you trust the recommendation or not, you can verify the work.

What This Actually Means

I want to be precise here, because the productivity claims around AI-assisted development are frequently vague and self-serving. Let me give you concrete, grounded estimates based on my experience managing engineering teams at scale.

The Traditional Development Equivalent

The system described above represents a specific and estimable body of engineering work. Here is my honest assessment of what it would have required through conventional development:

Original-scope traditional total: 35–47 weeks with a team of 3 engineers. Extended-scope traditional total — what the platform actually is today: 84–113 weeks, which is roughly two years of a four-to-five-person team. At fully-loaded Manila market rates — conservative at $8,000–12,000 USD per month per senior engineer — that's a burn of $640,000–$1,400,000 USD for the team-and-time it would have taken through conventional development.

With Claude Code, one person built the equivalent in nine months of elapsed time, at the cost of a Claude subscription and GCP infrastructure. The capital efficiency is not incremental. It is categorical.

The Important Qualifications

I want to be careful not to oversell this, because the nuances matter for anyone considering a similar path.

• Domain expertise is not optional. Claude Code amplified my ability to build. It did not replace the 20+ years of experience that enabled me to know what to build, how to architect it, and when something was wrong. The P0 bugs were caught because I understood the scoring logic well enough to know the outputs were suspicious. A less experienced founder would not have caught them.
• Governance is as important as velocity. The sessions where I had clear architectural intent, a well-maintained CLAUDE.md, and a disciplined git workflow produced good outcomes. The sessions where I didn't produced technical debt and, in some cases, bugs that made it into the pipeline.
• The human is still the architect. Every major architectural decision — the stage contract pattern, the three-mode GCS routing, the tenancy hierarchy, the scoring rubric design — originated from human reasoning. Claude Code executed with extraordinary effectiveness. It did not originate the strategy.
• Quality verification cannot be skipped. AI-generated code at scale requires systematic auditing. The pipeline audit that discovered the P0 bugs was the result of investing time in deliberate verification — something that is easy to skip when velocity is high.

What This Means for the Industry

I've built software teams in some of the largest technology organisations in the Philippines. I've managed engineers across multiple countries, negotiated vendor contracts, and overseen technology transformations at institutional scale. My perspective on what this moment represents is therefore not that of someone who has only ever worked alone.

What is happening right now is a structural shift in the production function of software. The minimum viable team for building a sophisticated SaaS platform is collapsing. Not because engineers are becoming less valuable — but because the leverage available to a skilled technical leader has increased by an order of magnitude.

This has profound implications for how early-stage ventures are funded, staffed, and evaluated. A solo technical founder with deep domain expertise and disciplined AI collaboration practices can now produce what previously required a seed-funded team. The "build it to prove it" phase — the most capital-intensive and time-intensive phase of any startup — just got dramatically shorter and cheaper.

For enterprise technology leaders — CIOs, CTOs, VPs of Engineering — the implication is different but equally significant: the teams you are managing need to evolve toward this mode of working, not resist it. The engineer who is 10x effective with AI tools is not a curiosity. They are the new baseline expectation. Your job as a technology executive is to build the governance frameworks, the quality assurance practices, and the architectural discipline that makes AI-augmented development trustworthy at scale.

I started this piece with a logistics ERP written in C, built by someone with dyslexia who had no business pulling it off. The throughline from that system to Intelletto.ai is the same one it's always been: technology is leverage. What's changed is the magnitude of that leverage. And what stays the same — what will always stay the same — is that the person holding it still has to know what they're building, and why.

There's a tidy symmetry to the Audit Report being the last thing we shipped before publishing this. The article is fundamentally an argument for accountability — that solo founders building serious systems with AI should be expected to govern their work in a way that's trustworthy at scale. The Audit Report is the system literally producing a trustworthy artefact of its own work, on demand, in a form an auditor can verify without trusting us. If I'm going to make the claim that one founder and one AI can build something a regulator would be willing to evaluate, the system needs to make the same claim about itself — and prove it. Now it does.

If you're building something ambitious, I'd encourage you to find out what's now possible. The barrier to production-grade sophistication has never been lower. The discipline required to use that capability responsibly has never been more important. And the bar for what counts as "trust me, it works" has, for systems that matter, risen to "here is the signed report — verify it yourself."