AI Consulting · Applied Engineering

We build the system.Not the slide deck.

ADJL Technology works out where AI actually belongs inside a business that already runs. Then we build that thing, put it into production, and hand it over with the code. The first client was our own firm. The underwriting engine behind ADJL Capital’s property deals is ours, and it ran on our own capital before it ran on anyone else’s.

Three practices. One team. Software that’s already running on the firm’s own money.

  • Real estate A listing URL in, a full underwriting out
  • Trading firms Market data, execution and network work
  • AI implementation Built into the workflow you already run
  • Ownership You keep the code, the data and the models

AI Consulting & Engineering

Three practices,one discipline.

The three look unrelated until you notice they’re the same job. Somebody is making a decision slowly, by hand, out of incomplete information. We build the thing that makes it faster, repeatable and checkable. The domain changes. The work doesn’t.

01

AI Implementation

For businesses that already work

We start at your workflow, before we go anywhere near a model. Somewhere in a business that already runs, capable people are spending their best hours reading, sorting, extracting and routing. That work is expensive because it’s repetitive and still needs judgment. We build the narrow thing that does one of those steps, put a human where being wrong is costly, and instrument it so you can tell whether it’s helping.

  • Retrieval over the documents you already have
  • Extraction from records that were never structured
  • A review gate wherever the cost of being wrong is real
How we implement
02

Real Estate Intelligence

The underwriting engine

Paste a listing URL. The system resolves the address, pulls live rents and comparables, reads years of public records, and models tax including the reassessment that lands on sale. What comes back is the underwriting an analyst would have spent a day on. Every figure carries its source, and anything unaudited says so on its face.

  • Live market data and comparables, not a national average
  • Public records read directly, going back years
  • Every number carries provenance or it doesn’t ship
How the scanner works
03

Trading Infrastructure

Programming and network solutions

The plumbing a trading firm runs on: market data ingestion and normalization, order and execution pipelines, network and latency work, and backtesting harnesses that run the same code path as production, so a backtest can’t quietly diverge from the thing it’s supposed to predict. We describe what a system is for and how it behaves, and never how to rebuild it.

  • Market data ingestion, normalization and storage
  • Execution pipelines and order routing
  • Backtests that share a code path with live
What we build

How An AI Build Runs

How a problem becomessomething that runs.

Most AI projects die between the demo and the Tuesday after it. This is the sequence that avoids that. It works because nothing gets built until the thing it’s replacing has been watched in the wild.

watch 01 map 02 build 03 measure 04 handover 05
  1. 01

    Sit with the work

    We watch the actual process, with the people who actually do it, before we propose anything. Almost every workflow has a step nobody documented, because it lives in one person’s head.

  2. 02

    Find the one step

    We pick one step. It has to be expensive, repetitive, and survivable if it’s occasionally wrong. Choosing the step is most of the job, and choosing a glamorous one is how these projects fail.

  3. 03

    Build the narrow thing

    A system that does that one step and nothing else. Narrow is what makes it possible to say whether it works. A narrow thing that ships beats a broad one that’s still in review.

  4. 04

    Instrument it

    Before it goes live it gets an evaluation set and a way to see what it did and why. A system nobody measures is a system nobody can defend when it gets questioned.

  5. 05

    Hand it over running

    You get the code, the prompts, the evaluation set and the documentation. The engagement ends with your team able to change the thing without calling us.

This sequence is slower to start than buying a tool. That’s the trade. The first two stages produce no software at all, and skipping them is how you end up with the demo that nobody owns.

Selected Work

Systems that areactually running.

Three builds, described by mechanism instead of outcome. Each page walks the system stage by stage: what goes in, what each stage does with it, and the decisions inside it a buyer would otherwise have to ask about.

Underwriting Automation

Watch itdo the work.

A sentence like “it underwrites the property” is easy to disbelieve. This is the same claim with its working shown. You watch the address resolve, the records come back, and the numbers land.

A recorded transcript of the underwriting engine, not a live tool.

Engagement Process

What it is liketo hire us.

Four steps, and the first one is free. By the end of the second you have a written scope with a price on it. By the end of the fourth your team owns a system that’s running.

  1. A conversation 01

    You describe the problem

    A call with Daniel and whoever will lead the build. No qualifying call before the real call, and no salesperson in the room.

  2. Week one 02

    We watch it happen

    Time with the people doing the work today, and with the systems holding the data. This is where the actual problem usually turns out to be somewhere else.

  3. Written down 03

    A scope, in writing

    You get the one step we’d build, what it would cost, what it would take, and what has to be true for it to work. Priced and dated before anyone commits to it.

  4. Then it ships 04

    Built, measured, handed over

    The build runs against an evaluation set from the start. It goes live behind whatever review gate the risk deserves, and it ends with your team owning it.

Languages, Models & Infrastructure

What the work is actually built out of. No preference here is a religion. The constraint picks the tool.

Languages & runtime
  • TypeScript
  • Python
  • Node.js
  • Rust
  • SQL
  • C++
Models & retrieval
  • Claude
  • OpenAI
  • Local / open weights
  • Vector search
  • Structured extraction
  • Evaluation harnesses
Data & infrastructure
  • Postgres
  • Supabase
  • Redis
  • Kafka
  • Parquet
  • Time-series stores
Delivery
  • AWS
  • Netlify
  • Docker
  • Terraform
  • GitHub Actions
  • Observability

The Team

You talk to Daniel.A team builds it.

ADJL Technology is Daniel Laskowski and a team of developers. He takes the first call, writes the scope, and reads every message that arrives at the address on this page. There’s no account manager standing between you and the person accountable for the work.

The team is small and senior on purpose. That’s an engineering decision, not modesty. A brief loses something at every hand it passes through, and a system built by people who were all in the original conversation needs far less documentation to stay understood a year later.

The software behind ADJL Capital was built here: the property underwriting engine and the rules-based system for liquid US equities. It runs on the firm’s own capital before it runs on anyone else’s, and the client work is held to that same standard.

Fair Questions

The things youare actually thinking.

How big is the team, and who actually does the work?

Daniel founded the firm and leads every engagement. He scopes the work and stays on it through delivery. The build is done by a small senior development team, and you meet the people who are on yours. There’s no bench of juniors a brief gets handed down to, and nobody translating between you and the engineers.

Is this just a wrapper around someone else’s model?

The model is one component, and usually the least interesting one. The work is in getting your data to a state where a model can act on it, deciding where a human has to stay in the loop, and building the evaluation that tells you whether any of it works. Swap the model out in a year and that scaffolding is what you keep.

We already have developers. Where do you fit?

Usually alongside them. We’re not there to replace anyone. An in-house team knows the business far better than we will in week one. What they often don’t have is spare capacity, or a reason to have built this particular thing before. We build the piece, work in your repository against your conventions, and hand it to your people to carry. They’re the ones who’ll still be here in a year.

Who owns the code when we’re done?

You do. The code, the prompts, the evaluation set and the documentation, in your repository, with no license back to us and no runtime dependency on anything we host. There’s no version of this where you have to keep paying to keep using what you paid to have built.

What about our data?

It stays in your environment wherever that’s possible. Where it isn’t, you’re told exactly what leaves, where it goes and how long it lives there. You get that before anything is built, not in an appendix afterward.

How is this related to ADJL Capital?

ADJL Capital is a private investment firm with three partners. ADJL Technology is a separate company, founded and led by Daniel Laskowski with its own development team. The software the fund runs on was built here, which is why we can describe it in this much detail. It’s our own. Neither firm owns the other, and nothing on this site is an offer of any security.

Start Here

Tell us whatis slow.

The most useful first message isn’t a brief. It’s one paragraph about the step in your business that costs the most and moves the slowest. If you know why the obvious fix hasn’t worked, say that too.

Daniel reads and answers these himself, usually within a day or two. There’s no sequence, no drip, and nothing sold to anyone.