TECHNICAL FLUENCY · BUILT FOR SALES IMPACT

Sales-first. Technically fluent on purpose.

Since 2025 I have built hands-on technical projects to understand product workflows, front-end and back-end concepts, AI-assisted tools, and the systems behind the products I sell.

One question, answered in order below: why should a quota-carrying Account Executive’s hands-on technical fluency matter? Starting with where the line is.

Built with AI assistance, and that is the claim

Every system here was built with heavy AI tooling assistance. Stating that first is deliberate: the interesting skill is not typing the code, it is directing those tools to produce a codebase that enforces its own invariants — computed ledgers instead of hand-maintained counts, contract tests, guards watched failing before they are trusted.

Those are judgment calls a model does not make on its own, and they are what I would actually bring to a conversation about adopting this tooling.

If you want to go further

The engineering record behind the fluency

Twelve self-directed systems since roughly mid-2025, built while carrying a quota. Three of them carry most of the evidence below: o.Kashik, a local-first AI platform; a local-first desktop application and its discovery engine. This section exists so a technical evaluator can check that the fluency above is real. It is not a case for hiring me as an engineer.

19
Rust crates in one workspace
o.Kashik, a local-first AI platform: agent runtime, provider-agnostic model gateway, MCP adapter, tool registry, containment over untrusted files, and an approval that binds to an action rather than to its text. One substantial Rust project — not production Rust.
- Rust
36
Architecture decision records
Written decisions with explicit supersession, in one local-first Electron and TypeScript desktop application with sandboxed renderers. Two of them were each individually correct and resolved to different databases, which is the defect that made me write the third about how they compose.
- Electron
- TypeScript
16
Executable contract tests
TypeScript tests whose subject is an agreement rather than a function — including one asserting properties of the CI pipeline itself, written because that pipeline had never executed once and nothing reported it.
- TypeScript
5
Enforced safety gates
On that application’s Python discovery engine, which records a blocked request as a source failure rather than evading it. A CAPTCHA, rate limit, or robots denial is logged, never worked around. It also cannot write to the store it reads for — the scanner and the record are separated on purpose.
- Python
9
Sequential SQL migrations
Against SQLite, with a ledger, and every shipped migration frozen. Editing one passed 68 of 70 tests, because every test built a fresh store — which is why the rule exists.
- SQLite

What this is not

Not professional engineering employment. Every system here was built solo, and every defect described was found and fixed by the person who wrote it. That is genuinely weaker than peer review.
Not production. One user, one machine, no traffic, no uptime obligation, no on-call.
Not machine learning. Building on top of models is API consumption and systems work.
Not a security qualification. Static analysis running in CI is a tool used correctly, not a credential.
Built with heavy AI tooling assistance, stated here rather than waiting to be asked.

The discipline is the transferable part, and it is what I would bring to a technical sales conversation: computed rather than hand-maintained numbers, checks watched failing before they are trusted, and limits written down where a reader can find them.

What recurs

Six ideas that keep showing up

Each arrived through a specific failure, so each is stated with the defect that produced it. A principle with no defect behind it is a slogan.

Correctness is not compositional
When adding a rule, ask which existing rule it now has to coexist with. Where two things interact implicitly, give the interaction a name and a place to live.
What produced it: Two architecture decisions, each individually correct, resolved to different databases. A quoting engine had the same shape earlier: two discounts that were each within policy stacked through the price floor.
In a deal: It is the same failure as two correct comp plans that reward opposite behavior. I look for it in a prospect’s process before it shows up in their forecast.
A check whose failure mode is silence is not a check
The useful question is never “did it pass?” — it is “what would tell me if it stopped being correct?”
What produced it: CI workflows committed for months that had never executed once, because a subdirectory cannot host them. A verify script that tested the wrong tree and would have reported clean over broken code. A governance file nothing ever loaded.
In a deal: A pipeline review that only ever confirms the number is the same defect. I would rather find out a stage is wrong in week two than at quarter end.
Record provenance while you still have it
Provenance is cheap at write time and unrecoverable afterwards.
What produced it: A dataset where nine of fifteen columns describe the data rather than the place. Digests stored for every prompt source. Release hashes recovered and validated before old installers were deleted.
In a deal: Where a number came from is the first thing anyone asks about a forecast, and the last thing anyone records.
Deliberately building something less capable
Writing down what you are choosing not to build is a distinct engineering act, and it produces systems you can describe honestly.
What produced it: A planner that refuses to invent market data and flags it for validation. A scanner that records a CAPTCHA as a failure rather than evading it. Observability sequenced before automation, on purpose.
In a deal: The same instinct as scoping a pilot down until it can actually succeed, rather than promising the full platform in ninety days.
Identity over description
Bind a decision to the thing itself, not to a description of it. Absent and explicitly-empty are different states.
What produced it: An approval that bound to the text of an action rather than the action — a one-line confused-deputy defect. A glyph that meant both “evaluated” and “employer verified”, which cleared a safety gate it should not have.
In a deal: Verbal agreement is not a signed order form, and a CRM that cannot tell them apart produces a forecast nobody trusts.
The ratchet: accept the present, constrain the direction
Set a budget at today’s real number and allow it only to move one way. It removes the argument about the current state entirely.
What produced it: A raw-colour budget that may only be lowered. Known limitations that move to the changelog in the change that resolves them, never before.
In a deal: How I would run a territory I inherited: do not relitigate the pipeline you were handed, just make it only able to improve.

Scope

Where the Line Is

Hands-on building makes me a better Account Executive — sharper in discovery, more useful in a demo, and more accurate about what implementation will cost. That is the whole argument, and here is exactly how far it goes.

This page argues that hands-on technical work makes me a better Account Executive. It is not an application for an engineering role. Both halves of that are worth stating precisely.

What I can do credibly

Run deeper technical discovery — ask what a system actually does, follow the answer, and ask the next question rather than the scripted one.
Read API and integration documentation, and tell from it whether an integration a prospect needs is straightforward or a project.
Reason about workflows and data models well enough to spot where a buyer’s process and a product’s assumptions will not meet.
Build and deploy working prototypes end to end.
Recognise common implementation risks — the migration nobody scoped, the permission model that will not fit, the data quality problem that surfaces in month three.
Communicate with product and engineering in their terms, which shortens the round trip on every question a deal depends on.
Recognise when a solutions engineer or specialist should be in the room, and bring them in with the question already narrowed.

What I am not claiming

Senior software-engineering proficiency.
Enterprise architecture ownership.
Security-engineering specialisation.
Production-infrastructure expertise.
That I replace a dedicated solutions engineer.
Machine-learning engineering. Building on top of models is API consumption and systems work, not model work.
Peer-reviewed practice. Every system was built solo, and every defect I describe was found and fixed by the person who wrote it.
Production operation. One user, one machine, no traffic, no uptime obligation, no incident history.
Production Rust. One substantial Rust project is the honest phrasing, and it is the one I use.

The value is in the overlap: enough technical depth to be useful in a technical conversation, and a sales record that says where my attention actually goes.

Why it matters

How Technical Fluency Improves Selling

Seven mechanisms, each tied to one verified project or employer example — and each linking to it.

Discovery
I can ask what happens to the data after it is entered, and understand the answer well enough to find the gap the product actually closes.
Evidence
Building a CRM meant choosing pipeline stages, cadence behavior, and consent handling myself — so I know which discovery questions have real answers behind them.
See it
Qualification
Reading the integration surface early tells me whether a deal has a hidden implementation project inside it, which is a disqualifier worth finding in week one rather than week nine.
Evidence
The lead engine scores profile fit separately from buying signal, because I had to decide what actually disqualifies an account rather than inheriting a vendor’s single score.
See it
Demonstrations
I can leave the demo path when a prospect asks a real question, because I understand what the product is doing rather than the order of the clicks.
Evidence
Across my full SunPower tenure, 34% of held demonstrations closed — the product needed explaining before it could be sold, and the explanation was the sale.
See it
Buyer trust
Being able to say plainly what a product will not do is what makes the rest of what I say worth believing. That requires knowing.
Evidence
The quoting engine enforces its pricing floors in code rather than in a playbook, which is the kind of specific answer a governance-minded buyer is actually asking for.
See it
Product and engineering alignment
I can write a feature request that an engineer can act on — the state, the trigger, the edge case — instead of relaying a customer sentence.
Evidence
A 24-domain knowledge graph with typed relations and a controlled vocabulary is public and inspectable; that is the same discipline a good requirement needs.
See it
Implementation handoff
I would rather lose a deal than hand implementation an account whose expectations the product cannot meet. Knowing what onboarding will hit is what makes that judgment possible.
Evidence
In solar, cancellations almost always traced back to something skipped in discovery rather than to the install — which is where the habit came from.
See it
Risk detection
I notice the permission model, the data migration, and the compliance requirement before they become a stalled deal in legal review.
Evidence
Enforcing do-not-call suppression at the database rather than the interface was a decision about where a guarantee has to live to be real.
See it

Capabilities

Capability and Evidence Matrix

What I can do, where to check it, why it matters commercially, and where it stops. The boundary column is what makes the rest credible.

Agent orchestration and AI integration
Build systems on top of language models — provider abstraction, an agent runtime, tool governance, prompt provenance — and design around how a model fails rather than around what it can produce.
Evidence
A local-first platform of 19 Rust crates carrying an agent runtime, a provider-agnostic model gateway, an MCP adapter, and durable invocation identity so one invocation means exactly one run. An earlier planner refuses to generate market data at all and flags it for validation instead, because a model asked for a business plan returns an invented TAM formatted exactly like a real one.Check it
Sales relevance
I can tell from a prospect’s architecture whether swapping model providers is a configuration change or a rebuild, and I can hold that conversation without a specialist in the room.
Boundary
Not machine learning. No training, no fine-tuning, no evaluation science, no model architecture work. Building on top of models is API consumption and systems engineering, and calling it AI/ML collapses the moment someone asks about loss functions.
Contracts, schemas, and interface design
Define the shapes that cross a boundary, version them, generate code from them, and test that the boundary holds — including where absent and explicitly-null have to mean different things.
Evidence
Four JSON Schema contracts with hash-stable resolution and per-field provenance recording what an override displaced. Catalog validation treats the file set as a cross-file graph and rejects two competing authority roots outright, because dangling references and cycles are properties of the graph and invisible from inside any single file.Check it
Sales relevance
Integration scoping is mostly a schema question. Given a prospect’s data shapes I can usually tell whether their integration is a week or a quarter, which is the number a forecast depends on.
Boundary
No public API with external consumers. Nothing anyone else has integrated against, no deprecation cycle run with real users, no SDK maintained.
Security and safety boundaries
Reason about privilege, trust boundaries, and what a system should be structurally prevented from doing — then make the dangerous path expensive rather than merely documented.
Evidence
Five enforced gates on a discovery engine: a CAPTCHA, rate limit, or robots denial is recorded as a source failure rather than evaded, and the scanner can never write to the tracker. Privileged desktop operations route through a context-isolated preload API, so a new capability needs four coordinated changes and none of them arrives by accident.Check it
Sales relevance
Every AI company asks the responsible-use question. I can answer it with decisions I actually made, which lands differently from reciting a policy.
Boundary
Not a security qualification. No certification, no penetration testing, no threat-modelling training, and no security review from anyone qualified. Static analysis running in CI is a tool used correctly, not a credential.
Testing and self-verification
Write checks that fail when a published claim drifts from the thing it describes, not only when code breaks.
Evidence
This site publishes its own Playwright test count and build totals, and a hand-written audit script recomputes both from the real suite and the real data — it has failed the build twice for numbers that had gone stale.Check it
Sales relevance
It is the same instinct as accurate pipeline reporting: compute the number rather than remember to update it.
Boundary
A handful of scripts on one small site, not a quality-engineering practice.
APIs and integrations
Read API documentation and implement against it — OAuth flows, webhooks, scheduled jobs, and bidirectional record sync.
Evidence
A full OAuth authorize and callback flow with records reconciled in both directions, plus telephony and transactional email integrations.Check it
Sales relevance
I can tell from a prospect’s integration requirements whether they are a configuration or a project, which changes the timeline I commit to.
Boundary
I have not built or operated a public API that other companies depend on, and I do not have experience with enterprise iPaaS platforms.
Data and schemas
Design a relational schema, write sequential migrations, and model entities and relationships across domains.
Evidence
17 hand-authored Postgres migrations in the CRM; a public 24-domain graph with 1,475 records, typed relations, and a controlled vocabulary.Check it
Sales relevance
Data-model conversations are where CRM and analytics deals are actually won. I can follow one, and notice when a buyer’s entities do not fit the product’s.
Boundary
No experience with data warehousing at scale, query optimisation under real load, or analytics engineering as a discipline.
Workflow automation
Build multi-step automated pipelines that run unattended, report their own failures, and grade the confidence of what they produce.
Evidence
A scheduled scrape, enrich, score, store, and review pipeline with per-record provenance and a self-reporting coverage audit.Check it
Sales relevance
Most of what SMB buyers want is workflow relief. I can identify which step in their process is actually costing them and speak to it concretely.
Boundary
These run at personal scale. I have not operated a pipeline with uptime obligations or on-call responsibility.
Front-end prototyping
Build and ship working interfaces — React and Next.js with TypeScript, responsive and accessible by default.
Evidence
This site, plus MetraNode and LogiMap Ultimate, both public and deployed. LogiMap is deliberately small enough to read end to end.Check it
Sales relevance
I can build a rough version of what a prospect is describing, which turns an abstract requirements conversation into a concrete one.
Boundary
Prototype quality, not product quality. No design-system ownership, no large-team front-end architecture, no performance work at scale.
Sales-system design
Design the mechanics of a sales system — pipeline stages, cadence behavior, discount governance, lead scoring, compliance enforcement.
Evidence
Three private commercial systems built specifically to understand the category: CRM, quoting, and lead intelligence.Check it
Sales relevance
This is the capability that matters most. When selling to a sales organisation, I have made the design decisions their buyer is evaluating.
Boundary
Built for a single operator. I have not designed for multi-team hierarchies, territory management at enterprise scale, or complex compensation.

Artifacts

Three Decisions, Annotated

Small examples, each with the decision, the trade-off, how it was validated, and why a sales organisation should care.

A guarantee that cannot be clicked past
Problem. Do-not-call suppression implemented as a disabled button protects exactly one path — the one the designer thought of. A bulk action, a background job, or a second client bypasses it silently.
```
-- Enforcement lives with the data, not the component.
create policy "no_contact_when_suppressed"
  on call_attempts for insert
  with check (
    not exists (
      select 1 from dnc_registry d
      where d.phone = call_attempts.phone
    )
  );
```
Decision
Express the rule as a row-level-security policy in Postgres, so the write is rejected by the database whatever issued it.
Trade-off
Policies are harder to read than an if-statement, and the failure surfaces as a database error that the interface has to translate into something a human understands. That translation work is real, and it is worth it.
Validation
Covered by tests that attempt the write directly, bypassing the interface entirely. A test that goes through the UI would not prove anything about the guarantee.
What I learned
Where a rule lives determines whether it is a guarantee or a suggestion. That is a design question, not an implementation detail.
Why a sales org cares. When a security-minded buyer asks how consent is enforced, "the button is disabled" and "the write is rejected" are different answers — and only one survives follow-up questions.
Two signals that must not be averaged
Problem. A single lead score blends "looks like our best customers" with "appears to be buying now". The same number then means two opposite situations, so it cannot be acted on.
```
# Fit and intent stay separate all the way to the seller.
@dataclass
class LeadScore:
    profile_fit: float     # 0-1, against a written ICP thesis
    buying_signal: int     # 0-100, observed activity
    confidence: str        # how well-sourced this record is

    def quadrant(self) -> str:
        hot = self.buying_signal >= 60
        fit = self.profile_fit >= 0.6
        if fit and hot:  return "work now"
        if fit:          return "nurture"
        if hot:          return "poor fit, active — usually a trap"
        return "ignore"
```
Decision
Keep fit, intent, and confidence as three separate fields, and derive the recommendation from the combination rather than collapsing them into one number.
Trade-off
Three fields are harder to sort a list by than one. A blended score is genuinely more convenient, which is exactly why it is the default and why the default is wrong.
Validation
Checked by walking known accounts through the quadrants and confirming the recommendation matched what I would actually have done with each.
What I learned
Convenience in a data model tends to be someone downstream losing information they needed.
Why a sales org cares. Every sales-intelligence product will be asked what its score means. Having built both the blended version and the separated one, I know which question to ask a vendor and which answer to distrust.

Discovery

Questions I Can Ask Because I Built the Systems

Ten questions across five areas, each naming what the answer changes — plus eight technical concepts translated into commercial terms.

A technical question is only useful when its answer changes qualification, scope, risk, demonstration strategy, or handoff. Everything else is trivia, and trivia in a discovery call spends credibility instead of building it.

Integrations

“When the same field changes in both systems, which one wins?”
Why it matters
Every bidirectional sync has to answer this, and many answer it by accident. "Last write wins" is a real policy with a real consequence: the system that is edited most often silently becomes the source of truth, whether or not anyone chose that.
What the answer changes
If there is no explicit conflict rule, the integration is a scoping conversation rather than a configuration step, and it belongs in the implementation plan before the contract rather than after.
- Scope
- Risk
- Handoff
Earned by: Building a bidirectional CRM sync, where I had to pick the rule and live with what it overwrote.
“What usually breaks first when a customer’s CRM data is incomplete or inconsistently formatted?”
Why it matters
Asked this way it invites a real answer instead of a reassurance. Every vendor has a list, and the honest ones answer immediately because they have seen it — phone formats, missing owners, duplicate accounts.
What the answer changes
The answer tells me whether to demo against clean sample data or against something messy. If a prospect’s data is worse than the failure point described, that is a pre-sale data conversation, not a post-sale surprise.
- Qualification
- Risk
- Demo strategy
Earned by: Running lead enrichment on public data, where inconsistent formatting was the default rather than the exception.

Data quality

“What determines whether two records represent the same person or company?”
Why it matters
The deduplication key is a product decision disguised as a technical one. Matching on email address, domain, or a fuzzy name comparison produces three different customer databases from identical inputs.
What the answer changes
A weak or undisclosed matching rule means the customer will discover duplicates in month two. Knowing the rule lets me set that expectation during the sale instead of leaving it for onboarding to absorb.
- Scope
- Risk
- Handoff
Earned by: Building a lead pipeline where the same company arrived from several sources and had to be reconciled.
“Which fields are sourced, which are inferred, and how is that difference shown to the user?”
Why it matters
Most enrichment products blend verified data with model guesses and present both in the same typeface. A seller acting on an inferred job title does not know they are guessing.
What the answer changes
If the interface does not distinguish them, the product will be trusted more than it deserves and blamed when it is wrong. That is worth surfacing in the demo rather than discovering in a renewal conversation.
- Qualification
- Risk
- Demo strategy
Earned by: Grading confidence per record in my own pipeline, because the sources genuinely differed in reliability.

Security and access

“Is record access enforced only in the application, or also at the database layer?”
Why it matters
Application-only enforcement protects the paths someone thought of. An export, a background job, a reporting tool, or a second client can route around it — and usually one of those exists.
What the answer changes
For any buyer with a security review, this determines whether the deal clears it. Asking early means finding out in week one rather than after legal has already been engaged.
- Qualification
- Risk
- Scope
Earned by: Moving access rules into row-level security policies in Postgres, having first written them as conditionals in the interface.
“How are do-not-call and communication restrictions enforced — when the record is written, when the message is sent, or both?”
Why it matters
These are different guarantees. Enforcement at send time still allows a suppressed contact to sit in a campaign until something tries to reach them; enforcement at write time keeps them out of the list entirely. Only "both" is actually safe.
What the answer changes
For a regulated buyer this is a gating question. A vague answer is itself the answer, and it belongs in the risk section of the deal review rather than in a footnote.
- Risk
- Qualification
- Handoff
Earned by: Implementing suppression at the data layer in my own CRM, which is the decision the whole case study for it is about.

AI and automation

“What customer data is retained by the model provider, and for how long?”
Why it matters
The vendor is usually not the only party involved. Retention, training use, and region are three separate questions, and the answer to one does not settle the others.
What the answer changes
For any buyer with a data-protection obligation, this is pass or fail before feature comparison starts. It is the fastest disqualifier available in an AI deal, which makes it worth asking first rather than last.
- Qualification
- Risk
Earned by: Integrating an LLM API into a working application, which meant reading the data-handling terms rather than the marketing page.
“How are model outputs evaluated before they influence a customer-facing workflow?”
Why it matters
The gap between "the model suggests" and "the system acts" is where AI products either earn trust or lose it. A product with no evaluation step is asking the customer to be the evaluation step.
What the answer changes
If there is human review, the demo should show it, because that is the reassurance the buyer needs. If there is not, the deal needs a conversation about what happens when the output is wrong in front of a customer.
- Scope
- Risk
- Demo strategy
Earned by: Keeping generated drafts separate from human ones in my own tooling, so assistance could never silently overwrite the work.

Adoption and implementation

“Which user has to change their behavior for this to succeed?”
Why it matters
Software fails at adoption more often than at function. The person who has to work differently is frequently not the person buying, and if they were not in the evaluation they will not be in the rollout either.
What the answer changes
If the answer names someone absent from the deal, that person needs to be in it. This is the single best predictor of whether an implementation stalls, and it costs one question.
- Qualification
- Risk
- Handoff
Earned by: Leading a 20+ rep team where the ramp problem was behavioral, not informational — standardising what people actually did was what moved it.
“What is the expected time to first value, and what has to be true for that?”
Why it matters
The second half is the part that matters. Time to value is usually quoted assuming clean data, an available admin, and a decision already made — and one of those is normally missing.
What the answer changes
The preconditions become the implementation checklist, and they are far easier to agree before signature than to raise afterwards. It also stops me promising a timeline the product cannot meet.
- Scope
- Handoff
- Demo strategy
Earned by: Selling into SMB owners with no ops team, where every unstated precondition became my problem after the close.

Translation

Technical Concepts, Translated Commercially

Eight concepts a buyer will hear in a technical evaluation, in plain commercial terms — plus what to ask because of each.

Row-level security
Technical
Database policies decide which rows a query may return or write, evaluated when the query runs.
Commercial
Access is not enforced by hiding a button. The data layer itself decides which records a user can reach, so an export or an integration cannot route around it.
Ask this
Ask how permissions behave across teams, managers, exports, and integrations — not just in the interface.
Bidirectional synchronisation
Technical
Two systems exchange changes in both directions, requiring a conflict-resolution rule.
Commercial
Both systems can be edited and both stay current — provided someone decided which one wins when they disagree. If nobody decided, whichever is edited more often quietly becomes the truth.
Ask this
Ask which system wins on conflict, and whether that rule is configurable.
Deduplication key
Technical
The field or combination of fields used to decide that two records are the same entity.
Commercial
The rule that stops one customer appearing three times. Matching on email, on company domain, or on a fuzzy name comparison produces three different databases from the same inputs.
Ask this
Ask what the matching rule is, and what happens to the records it merges.
Webhook
Technical
An outbound HTTP request the system sends when an event occurs, rather than waiting to be polled.
Commercial
The system can tell other tools the moment something happens, instead of those tools checking every few minutes. The difference shows up as real-time versus almost-real-time.
Ask this
Ask which events fire webhooks, and what happens to the ones that fail to deliver.
Rate limit
Technical
A cap on how many API requests are accepted in a time window.
Commercial
A ceiling on how fast data can move between systems. It is usually invisible at trial volume and becomes visible during the first bulk import or migration.
Ask this
Ask what the limit is and whether a full historical import fits inside it.
Data provenance
Technical
Metadata recording where each value came from and how it was obtained.
Commercial
Being able to answer "where did this come from?" for any field. Without it, a wrong value cannot be traced, only argued about.
Ask this
Ask whether a field can be traced to its source, and whether the user sees that.
Migration
Technical
A versioned, sequential change to a database schema.
Commercial
The controlled way a system changes shape without losing what is already in it. Also the word for moving a customer’s existing data in, which is where implementations most often slip.
Ask this
Ask who owns the data migration, how long it takes, and what happens to records that fail validation.
Human-in-the-loop review
Technical
An automated output requires human approval before it takes effect.
Commercial
The system suggests and a person decides. This is the difference between AI that is trusted and AI that gets switched off after one bad customer email.
Ask this
Ask which automated actions require approval, who approves them, and what happens when nobody does.

Method

AI-Assisted Build Workflow

Eight steps. The four that used to be missing are the ones that separate using AI responsibly from generating code and hoping.

AI changed the scale of what I could attempt. It did not change my responsibility for understanding, reviewing, and validating the result.

01
Define the problem
States, triggers, and edge cases written down before anything is generated. Most bad output traces to a prompt that skipped this.
02
Inspect the current system
Read what already exists and what constrains it. Generating against an imagined codebase produces code that has to be thrown away.
03
Use AI for scoped acceleration
A bounded task with a stated interface, not "build me a feature". The narrower the scope, the less review it needs.
04
Review and revise by hand
Every generated line read and usually rewritten. Anything I cannot explain does not ship — that rule is the whole discipline.

Then, every time: run the checks · validate data handling and failure states · deploy and verify · document the limitations. The last is the one most likely to be skipped and the one that keeps the rest honest.

Progression

Learning Progression

Ordered phases rather than dates. The phase boundaries are not reconstructable from the artifacts, so they are not claimed.

Phase 1 · Foundation
FocusFrontend basics: HTML/CSS, JS, React, TypeScript
OutputsFirst Next.js portfolio iteration · early Notion systems
Sales whyMade me literate in modern web product structure
Phase 2 · Builds
FocusReal projects: STR Command Center, FL Studio Master Hub, Studio Writing Hub
OutputsOperational tools and content systems shippedSTR Command Center → case study FL Studio Master Hub → case study Studio Writing Hub → case study
Sales whyProves I can ship — not just learn — in parallel with quota
Phase 3 · AI Workflows
FocusClaude / ChatGPT / Gemini API integrations, prompt libraries
OutputsAI-assisted dev workflows · content automation pipelinesStudio Writing Hub → case study Palattes → case study
Sales whyLets me talk about AI adoption with grounded, firsthand examples
Phase 4 · Productization
FocusMetraNode, portfolio v3.0, deployment and user-facing polish
OutputsPublic sites at jaydrivesrevenue.comMetraNode → case study
Sales whyDemonstrates product thinking, deployment discipline, and user-facing judgment

Phase	Focus	Receipts
Phase 1 · Foundation	Frontend basics: HTML/CSS, JS, React, TypeScript
Phase 2 · Builds	Real projects: STR Command Center, FL Studio Master Hub, Studio Writing Hub	STR Command Center → case study FL Studio Master Hub → case study Studio Writing Hub → case study
Phase 3 · AI Workflows	Claude / ChatGPT / Gemini API integrations, prompt libraries	Studio Writing Hub → case study Palattes → case study
Phase 4 · Productization	MetraNode, portfolio v3.0, deployment and user-facing polish	MetraNode → case study

If you are hiring for a sales role where technical fluency is an unfair advantage — not a checkbox — let's talk.

Account Executive · Senior AE · fully remote. Start with the revenue record, or reach out directly.

See Revenue Results Contact Jay Download Resume

Sales-first. Technically fluent on purpose.

The engineering record behind the fluency

What this is not

Six ideas that keep showing up

Correctness is not compositional

A check whose failure mode is silence is not a check

Record provenance while you still have it

Deliberately building something less capable

Identity over description

The ratchet: accept the present, constrain the direction

Where the Line Is

What I can do credibly

What I am not claiming

How Technical Fluency Improves Selling

Discovery

Qualification

Demonstrations

Buyer trust

Product and engineering alignment

Implementation handoff

Risk detection

Capability and Evidence Matrix

Agent orchestration and AI integration

Contracts, schemas, and interface design

Security and safety boundaries

Testing and self-verification

APIs and integrations

Data and schemas

Workflow automation

Front-end prototyping

Sales-system design

Three Decisions, Annotated

A guarantee that cannot be clicked past

Two signals that must not be averaged

Questions I Can Ask Because I Built the Systems

Integrations

“When the same field changes in both systems, which one wins?”

“What usually breaks first when a customer’s CRM data is incomplete or inconsistently formatted?”

Data quality

“What determines whether two records represent the same person or company?”

“Which fields are sourced, which are inferred, and how is that difference shown to the user?”

Security and access

“Is record access enforced only in the application, or also at the database layer?”

“How are do-not-call and communication restrictions enforced — when the record is written, when the message is sent, or both?”

AI and automation

“What customer data is retained by the model provider, and for how long?”

“How are model outputs evaluated before they influence a customer-facing workflow?”

Adoption and implementation

“Which user has to change their behavior for this to succeed?”

“What is the expected time to first value, and what has to be true for that?”

Technical Concepts, Translated Commercially

Row-level security

Bidirectional synchronisation

Deduplication key

Webhook

Rate limit

Data provenance

Migration

Human-in-the-loop review

AI-Assisted Build Workflow

Define the problem

Inspect the current system

Use AI for scoped acceleration

Review and revise by hand

Learning Progression

If you are hiring for a sales role where technical fluency is an unfair advantage — not a checkbox — let's talk.