Nick Conenna — Applied AI Architect, Forward-Deployed — Cornelius, NC

I build applied AI systems, and I'm open to the right project.

Five systems, five domains I had no background in, built over two years — the kind of work that has to hold up in front of real users, not a demo. In practice that makes me a forward-deployed engineer: I go sit where the work happens, build inside the real constraints, and stay until it holds. Currently splitting time between those builds and new client work. If your project is a good fit, I'd like to hear about it.

The work: Work out which parts of a real process a model can be trusted with, design the system around that answer, build it, and stay with it until it holds up in front of actual users.
Any stage: Deciding whether something is worth doing, scoping it, designing it, building it, or picking up something that stalled. I'm useful at all of them and have no preference about where I come in.
Domains so far: Pricing and knowledge modeling for the trades. Agentic legal research and drafting. Consumer hardware and companion software for full-sphere imaging, earth and space. Long-form narrative built as a structured, versioned human/AI system. A consumer product built primarily on Claude. None fields I had worked in before. What they are ↓
Shape: Generalist by design. The transferable skill is not the domain — it's finding the part of a process where a model is trustworthy and building hard borders around the part where it isn't.
On-chain: Seasoned Bitcoin hodler and self-custodian — in the asset since early, still holding, still building around it. Runs as @BitcoinBroham on X, its own body of work here, not a footnote. Where it fits ↓
Terms: Full-time or contract. Remote, on site, or travelling. Based in Cornelius, North Carolina.

The work

What I do on a project

Most engagements are some mix of these. They're listed separately because teams tend to need them in different proportions.

Build the product

Take a piece from data model through integrations through the interface, and ship it. On small teams this is usually the whole job, and it's the shape I've been working in for two years.

Write and fix the software

The unglamorous half: it breaks on real data, it's slow, the edge cases pile up, the payment path has a race in it. Most of what determines whether an AI feature survives contact with users is ordinary engineering done carefully.

Run agentic systems, not just prompts

Wire a model up to tools, memory, and a task loop so it can actually do the work — not answer questions about the work. Most of my day-to-day, across all four systems, runs through agentic coding loops rather than one-shot prompting.

Work out the business problem underneath

The stated ask and the actual problem are often different. Twenty years running operations before this means I can usually tell which one I'm looking at, and say so early enough for it to matter.

Sit with the customer

Go where the work happens, learn the constraints that were never written down, build inside their environment, and leave it documented so their team runs it without me.

Pick up something that stalled

Find where it's actually failing, cut scope to what holds, get one path working the whole way through, and be clear about which parts still shouldn't ship.

Built

Five systems, five domains, one architect

These are the primary work samples. Pricing has to get a number right. Legal research has to get a citation right. A camera has to actually capture the sphere. A novel has to get a voice right. Five different failure modes, same underlying discipline — structure the domain knowledge, then decide exactly what the model is trusted to do with it.

Pricing & knowledge infrastructure

Fair Rate Index Live · v0.1

A free, public reference for what the eight core home and auto trades should cost, in all 50 states — built entirely on structured domain knowledge: task time, local labor rates from BLS data, material costs, and a regional index, published as a range rather than a false single number. A correction loop lets homeowners submit real invoices, and every verified submission pulls the band toward reality. The whole thing is exposed as an open API and JSON-LD so the numbers are machine-readable, not just a page.

Started

With no background in price modeling, trade economics, or turning a shop's cost structure into data a model can reason over.

My role

Architect and sole builder: the task dictionary, the pricing model, the correction loop, and the API that makes it queryable by anyone.

See it live at fairrateindex.com → · The build in detail → · 8 trades · 50 states · 400+ priced tasks · open API

Legal research & drafting

heyamicus Live

An agentic legal-research and drafting platform for civil and probate matters — document intake and timeline construction, statute and case research, deadline tracking, and drafting assistance, built out from a real active case rather than a hypothetical one. Live now, and in daily use by my co-builder, Julianna, pre-law at UNCW.

Started

With no background in civil procedure, probate practice, or turning statute and case law into structured, model-usable research.

My role

Architect and co-builder, alongside Julianna, who's working the underlying case from the client side and running the platform day to day.

See it live at heyamicus.com →

Consumer hardware & AI

YSKAIPE Building

A spherical camera and companion mobile app, built for both terrestrial and space use — full-sphere capture paired with an AI-driven app for shooting, reviewing, and sharing, rather than a 360° camera bolted onto a generic gallery app.

The hardware spec leans on the same extreme-environment instincts as my earlier field work: thermal regulation, redundancy planning, comms with no infrastructure to fall back on — what SpaceX's own Build Reliability org exists to do for avionics hardware. A camera meant to survive a spacecraft can't assume what a consumer camera assumes.

Started

With no background in optical hardware, embedded imaging pipelines, or designing a camera system meant to survive both a backyard and a spacecraft.

My role

Architect and builder: the hardware spec, the companion app, and the software stack tying capture, processing, and sharing into one system.

Not live yet — a dedicated build page is next.

Narrative systems

The Cubit and the Quark Book I published

A four-book roman-à-clef series — measurement, money, and who decides what counts — built as a structured, versioned production, not a single long draft. Book I, The Pace, is published: a prologue and 93 chapters across three parts, live as an ebook and paperback on Amazon, with an audiobook in production, byline Nicholas Conenna.

Started

With no background in fiction craft, series structure, or directing a model through a hundred-chapter continuity problem.

My role

Architect and author: the plot spine, the world's internal rules, and the editorial pass that keeps a hundred chapters consistent with each other.

Read more about the series ↓ · Book I: The Pace · ebook & paperback live · audiobook in production

Applied AI, built for fit

Built on Claude Building

A consumer product, hardware and software as one system. The software layer runs end to end on Claude; the hardware layer is being prototyped and fabricated through Grok Build's tooling, because that's the right tool for that layer, not a brand statement. Less a pitch than a demonstration — the clearest evidence I have of how I think and build, made for the team whose mission I actually want to work inside.

Started

With no fixed spec yet — built to show a way of working, not to sell a finished product.

My role

Architect and sole builder, across the Claude-driven software and the physical build.

Working name: TBD · not live yet — details to follow as the build firms up

Method

Four moves, in order, in any domain — and then again

This is a loop, not a checklist, and I mean that literally — every system above runs on agentic loops, not single passes. The fourth move returns to the first, and the reason most applied AI work stalls is that nobody ever closes it. The iteration is the product; I'd rather run twenty short passes than one long one.

Say it in their words

State the job the way the person who does it would state it. If I can't, I don't understand it yet, and no amount of clever prompting covers that up.

Give it the real material

Actual records, actual constraints, the thing everyone in the room knows and nobody wrote down. Systems underperform mostly because they were built against a description of the work instead of the work.

Build the check first

Before the interesting part: how will we know when this is wrong? A test, a known-good answer, a person who'd notice. Without one you can't improve a system, only hold opinions about it.

Correct in short passes

Run it again with what failed, visible each time, stop when it holds twice. Short passes beat one long unattended run.

Back to 01 — every pass changes how the job should be stated

Where I fit

The same job, under a dozen different titles

Postings call this different things depending on who wrote them. These are the ones that describe what I actually do — including the literal titles Anthropic, Coinbase, and SpaceX use for it.

Forward Deployed Engineer (FDE): Embedded with the customer, building inside their environment against their real constraints, and leaving something their team can run. The exact title both Anthropic and Coinbase use for this work.The shape I'm best at
Applied AI Engineer: Taking a capability and turning it into a product surface that holds up when the inputs are messy and the user is in a hurry. Anthropic's FDE org sits inside its Applied AI team; SpaceX runs the parallel role as AI Software Engineer.Product, evals, integration, the failure paths
Solutions Architect: Deciding what should be built before anything gets built, and being willing to say the honest answer is nothing. Coinbase runs this exact title on its Sales, Trading, and Prime team.Scoping, feasibility, the paid look
Founding Engineer: Whole product, one person, from data model to support inbox. Two years of doing exactly this — the same language Coinbase's own Forward Deployed Engineer postings use for someone embedded from day one inside a new team.Small teams, early stage
Application Software / Build Reliability Engineer: Where the work sits closer to hardware, this is SpaceX's own vocabulary: Application Software Engineer for the software layer, Build Reliability Engineer for making the physical layer underneath it hold up. YSKAIPE's camera system needs both.The SpaceX-shaped version of the same job
Technical generalist: Where the org needs someone who can move across pricing, legal research, physical systems, and narrative without a six-month ramp each time.Fintech and crypto infrastructure, aerospace and defense, hard tech, marketplaces, professional services
Crypto-native builder: A hodler and self-custodian since early in the asset, not a recent convert — I use the rails I'd be building, and I publish on Bitcoin and the space frontier as @BitcoinBroham. Fair Rate Index is the technical half of that: an open API and a public correction loop, where every number has to be right and auditable, not just plausible.Fit for any team building crypto-native products, not just watching the space

Honestly

What's hard about this work, and where I'm short

The last thirty percent isn't written down

Every domain has rules that live in one person's judgment. You don't get them by asking; you get them by building something slightly wrong and watching the expert react. That's why I'd rather start building at seventy percent understanding than wait for a complete specification that isn't coming.

I'm not a research engineer

My depth is applied — putting models to work. Training, fine-tuning, and evaluating at the frontier are other people's expertise, and I'd defer to them.

I haven't operated at very large scale

My production experience is systems with real users and real money in them, not millions of users. I know the difference between those two problems and I'm not going to pretend I've solved the second.

I've worked alone

Two years as the only engineer on everything I've built. I want the review culture of a strong team, and I expect the first month of that to cost me some ego.

I'm not hiding the toolchain, including the parts that aren't Anthropic's

The build made specifically to show fit with Anthropic runs its software on Claude and its hardware through Grok Build's fabrication tooling — because that was the right tool for that layer, not because of any hedge. I'd rather be visibly honest about tool choice than pretend the whole stack is one vendor's.

Not everything above is finished

Fair Rate Index and heyamicus are both live, and Book I of The Cubit and the Quark is published. YSKAIPE and the Anthropic-aligned build are real, active builds, not concepts — but they haven't yet been tested against anyone's constraints but my own. heyamicus is the exception: it's already in daily use against a real case, by someone other than me. That's the honest state of the rest, and it's exactly what a role or a serious contract would change.

Terms

Three ways this usually starts

Two weeks

A paid look

Find out whether the thing is worth doing, and say so plainly if it isn't. The cheapest way to learn you were about to spend six months on the wrong problem.

Six to twelve weeks

A defined piece

One process, one integration, one path to production. Scoped at the start, working at the end, handed over so your team owns it.

Full-time

On the team

Where the work is ongoing and the relationships matter more than any single project. This is the one I'd prefer, for the right mission.

Getting started: a short call to confirm scope, a one-page statement of work with a fixed price or day rate, then an invoice before kickoff on anything under six weeks — net 15 on longer engagements. No procurement maze on my end, and no separate "let's discuss pricing" round trip if you already know the shape of the work.

Rate on request Fixed price or day rate Wire / ACH USDC BTC

More detail

If you're building at SpaceX or a Musk company

The instincts under YSKAIPE's camera hardware — designing for a device that can't assume gravity, light, or orientation, and has to keep working with no one nearby to fix it — came out of earlier field work built explicitly around extreme-environment constraints: thermal regulation, redundancy planning, comms with no infrastructure to fall back on. That's the same short list of problems hardware teams solve at the vacuum end of the spectrum, at very different stakes.

See the mission →

Work sample 03

@BitcoinBroham — the same question, outside the fiction

An ongoing public ledger, not a brand account

MoneyandMeasurement

The novels ask who decides what counts. @BitcoinBroham is where I ask the same question in public, in real time, about an asset I've actually held since early — Bitcoin, self-custody, and the space frontier, written by a seasoned hodler rather than someone discovering the topic on camera.

It isn't a side account. It runs on the same discipline as the other systems on this page: a structured body of work, built in public, over years — and the clearest place to see how I actually think about money, trust, and verification before any of it shows up in client work.

Follow @BitcoinBroham →

Bitcoin · self-custody · the space frontier

Work sample 02

I write a novel series about measurement

A novel series in four volumes

The Cubitand theQuark

Measurement, money, and who decides what counts. A man is shot at four in the morning at the foot of Tesla's tower, and spends his last eleven minutes walking in a straight line, counting.

The research behind the fiction is the research behind the work: standards bodies, cryptography, energy, and the physics of the next fifty years. It is also where I do my reading.

Enter the series →

Book I: The Pace · published, ebook & paperback on Amazon · audiobook in production

THE PACE, by Nick Conenna — a hooded figure walks toward the Wardenclyffe tower under a clouded sky, ringed by faint geometric equations

Work sample 04

One sphere, two environments

A camera system built to work in both

EarthandSpace

Capture the whole sphere, not a framed slice of it — the same problem whether the thing behind the lens is a backyard or the inside of a spacecraft. A camera built for one environment quietly assumes gravity, light, and orientation; a camera meant for both can't.

YSKAIPE pairs the hardware with a companion app built to do the AI-heavy parts — capture guidance, review, and sharing — so the system is judged as a whole product, not a sensor with an afterthought of an app.

That discipline isn't new to me — it's the same one that shaped earlier field work in the Blue Ridge: thermal regulation, redundancy planning, and comms with no infrastructure to fall back on. A spherical camera meant for both a backyard and a spacecraft inherits the same constraints.

See the mission →

Spherical camera · companion mobile app · earth and space

Work sample 05

Built to show fit, not to sell a product

Hardware and software as one system

Untitledbuilt onClaude

Software end to end on Claude. Hardware prototyped through Grok Build's tooling, because that's the right toolchain for the physical layer — not a co-sign. The clearest evidence I have of how I actually think and build, made specifically for the team whose mission I want to work inside, not to sell anyone a product.

Full specifics are still firming up — this card will carry the real name and description once the build is far enough along to say plainly what it does and who it's for.

Consumer hardware + software · Claude-driven, Grok Build-fabricated

Why this work

The gains should reach the many

Most of the value in this technology is still sitting unclaimed inside ordinary work — the processes nobody writes conference talks about, in organizations that will never have a research team. Moving it there is a design problem and a translation problem, and both are solved by people willing to go sit where the work happens.

More advantage for a handful is an uninteresting outcome, and always was.

Get in touch

Tell me what you're working on

One paragraph is plenty. I answer email, and I'll tell you straight whether I'm the right person — including when I'm not.

The problem, in your own words
Role or project, and roughly when
What's already been tried
Rough budget or day-rate range, if you have one

nanonicholas@protonmail.com Book 20 minutes →

Cornelius, North Carolina · full-time or contract · remote, on site, will travel
Peaking Waters · The novels · Fair Rate Index · GitHub · LinkedIn · X