DEV Community: John Ughiovhe

We built an agent that turns messy RFQ emails into priced quotes, and shipped it on Alibaba Cloud

John Ughiovhe — Mon, 20 Jul 2026 18:40:59 +0000

Every distributor we spoke to has the same quiet bottleneck, and none of them call it a problem. They call it Tuesday.

A request for quote lands in a shared inbox. Sometimes it is a tidy bulleted list. More often it is three lines of text from someone's phone, or a PDF that was scanned at an angle. Someone on the sales desk reads it, works out which catalog part each line actually refers to, checks pricing, and types up a quote. A busy desk does this thirty or forty times a day.

It is slow, it is boring, and it is exactly the kind of work where a tired person on a Friday afternoon quotes the wrong bolt and nobody notices until the shipment arrives.

We spent three weeks building Distill.ai to do that job. This is what we learned, including the parts that went badly.

What we actually built

You paste an email or upload a PDF. From there a seven stage pipeline runs:

parse -> extract -> classify -> match -> price -> policy -> score

Parse cleans the document into text. Extract pulls out the individual line items, quantities, and specs. Classify works out what kind of request this is. Match maps each line to a real catalog SKU. Price applies the pricing rules. Policy runs the business checks. Score attaches a confidence value to every match.

The interesting part is not the happy path. It is what happens when the model is unsure.

Any line that scores below a 0.70 match threshold does not get quoted. It gets flagged with a reason and routed to a human review queue. A person confirms or corrects it, and the quote goes out clean.

That one decision is the difference between a demo and something a sales desk would actually put its name on. An agent that is confidently wrong 5% of the time is worse than useless in procurement, because someone has to check all 100% of the output anyway. An agent that says "I got 47 of these 50 lines, here are the 3 I could not resolve" saves real hours.

Why Qwen, and how we wired it up

We used two models from Alibaba Cloud Model Studio:

Qwen-Plus for extraction and classification, including tool calling
text-embedding-v4 for the 1024 dimension embeddings behind catalog matching

Model Studio exposes an OpenAI-compatible endpoint, which mattered more than we expected. Our provider layer is a thin fetch wrapper, and switching models is a config change rather than a rewrite:

const response = await fetch(`${env.LLM_BASE_URL}/chat/completions`, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${env.LLM_API_KEY}`,
  },
  body: JSON.stringify({
    model: env.LLM_MODEL,
    messages: [{ role: 'user', content: prompt }],
    temperature,
    max_tokens: maxTokens,
  }),
});

LLM_BASE_URL=https://dashscope-intl.aliyuncs.com/compatible-mode/v1
LLM_MODEL=qwen-plus
EMBEDDINGS_MODEL=text-embedding-v4
EMBEDDINGS_DIMENSIONS=1024

The embeddings go into Postgres with pgvector, so catalog matching is a similarity search against real SKU rows rather than keyword guessing. "M8 hex bolt, grade 8.8, zinc plated" and "Bolt, hexagon head, M8x50, 8.8, ZP" are not a string match, but they are close neighbours in vector space.

One deliberate choice: we deployed in Singapore (ap-southeast-1) specifically to sit next to the Model Studio endpoint. On a pipeline that makes several model calls per request, the round trips add up.

The stack

A NestJS modular monolith in TypeScript, split into two processes:

API takes the request, validates it, persists it, and enqueues a job
Worker consumes from Redis via BullMQ and runs all seven stages

Splitting them matters because parsing a 40 page PDF and calling a model six times is not something you do inside an HTTP request. The API answers immediately and the browser watches progress over Server-Sent Events, so you see each stage light up in real time instead of staring at a spinner.

Everything is containerized: api, worker, client (React and Vite behind Nginx), Postgres with pgvector, and Redis. The whole thing runs on a single Alibaba Cloud ECS instance via docker-compose, with Caddy in front for TLS.

Where it actually went wrong

The pipeline was the fun part. Deployment is where we lost days.

The migration step that could never have worked

Our deploy job ran database migrations inside the production container:

docker compose exec -T api pnpm migration:run

That script resolves to ts-node -r tsconfig-paths/register node_modules/typeorm/cli.js migration:run -d src/database/data-source.ts.

Now look at the production Dockerfile. The runner stage installs --prod dependencies only and copies dist/, not src/. So in the production image there is no ts-node, and there is no TypeScript data source. The command was guaranteed to fail the moment it touched a real server, and it had been sitting in the workflow the whole time because nobody had run a real deploy yet.

The fix is to point the TypeORM CLI at the compiled data source, which only needs packages that exist in the runtime image:

docker compose exec -T api \
  node node_modules/typeorm/cli.js migration:run -d dist/database/data-source.js

We checked that dist/database/data-source.js resolves entities and migrations through __dirname-relative globs, and confirmed no @-alias requires survive compilation. All 21 migrations then applied cleanly.

Lesson: your production image is a different computer. Any command in your deploy pipeline that you have only ever run locally is an untested command.

Boot loop over an empty string

The api and worker containers came up and immediately died, over and over:

Invalid environment variables: { SENTRY_DSN: [ 'Invalid url' ] }

Our env schema validates SENTRY_DSN as a URL. We were not using Sentry in this deployment, so the value was an empty string, and an empty string is not a valid URL. The variable was optional in spirit but not in schema.

Deleting the line entirely fixed it. Optional means absent, not blank.

A 4 GB box and an out of memory kill

We build images on the instance itself. On a 2 vCPU / 4 GB box, the client build got OOM killed partway through. Adding 4 GB of swap got the builds through. Not elegant, but it was the difference between shipping and not shipping.

Branch protection versus a deadline

Our staging and main branches require a pull request and three passing checks, and none of us can self merge. Correct policy. Also completely immovable at 11pm with a deadline coming.

So we brought the first release up by hand: git archive, scp to the box, docker compose build, migrate, up -d. Then we wrote the pipeline fix back as a proper reviewed PR, so the next deploy goes through CI like it should.

We do not regret the branch protection. Shipping around your own safety rails once, deliberately, and then closing the gap properly afterwards, is very different from not having the rails.

HTTPS without paying for a domain

We used Caddy with a DuckDNS subdomain. Caddy handles the ACME challenge and certificate renewal on its own, so the entire TLS configuration is this:

distill-ai.duckdns.org {
  reverse_proxy client:8080
}

Two lines and a real Let's Encrypt certificate. Then we locked SSH to a single operator IP and closed the raw API port, so the only public surface is the HTTPS front door.

What we would tell ourselves three weeks ago

Deploy on day two, not day nineteen. Every bug above was a deployment bug, not a logic bug. None of them were findable locally. The pipeline worked on our machines the whole time.

Confidence scoring is the product, not a feature. We nearly shipped without the review queue. The moment we added it, the whole thing changed from a party trick into something you could show a customer.

An OpenAI-compatible endpoint is worth real money in engineering time. We never wrote a Qwen-specific client. We wrote an HTTP client and changed a base URL.

"It runs locally" and "it runs in production" are separated by a surprising amount of unglamorous work. Swap space. Empty strings. Missing dev dependencies. None of it is interesting and all of it is required.

Try it

The deployment is live and open, no login required:

https://distill-ai.duckdns.org

The seeded catalog is zinc-plated fasteners, so write your RFQ around M6, M8, or M10 bolts, nuts, and washers. Here is one to paste:

Hi team, please quote the following for our new assembly line:
- 1500 x M10 hex bolts, grade 8.8, zinc plated
- 1500 x M10 hex nuts, zinc plated
- 3000 x M10 flat washers, zinc plated

We need delivery within two weeks. Kindly include pricing and lead time.
Regards, Sarah Bennett, Procurement, Northgate Industrial Ltd.

Watch the trace run, then open the review page. If one of the lines lands in the review queue rather than the quote, that is not a bug. That is the whole point.

Built with NestJS, TypeScript, React, PostgreSQL with pgvector, Redis, BullMQ, Docker, and Caddy, running on Alibaba Cloud ECS with Qwen-Plus and text-embedding-v4 via Alibaba Cloud Model Studio.

The 16-Day System and the 3-Day Feature: Two Internship Tasks That Changed How I Think About Backend Engineering

John Ughiovhe — Fri, 12 Jun 2026 02:25:46 +0000

A reflection on two backend engineering internship projects that shaped my understanding of system design, API architecture, and working within existing codebases.

When people ask what I worked on during my internship, the easiest answer is:

"I built APIs, authentication systems, and backend services."

Technically, that is true.

But that answer misses the most important part.

The most valuable lessons I learned didn't come from writing code. They came from dealing with complexity, making architectural decisions, and solving problems that were much bigger than they first appeared.

Looking back, two tasks stand out more than any others.

The first was Insighta Labs+, a backend platform that took about 16 days of active engineering effort across three progressive stages and pushed me deeper into system design than anything I had worked on before.

The second was building Funnel Display APIs for SEIL, a feature that took about 3 days of focused implementation and taught me another important side of backend engineering: how to extend an existing system without breaking its foundation.

One taught me how to build systems.

The other taught me how to build within systems.

Both changed how I approach backend engineering.

Task 1: Insighta Labs+ — Building One Backend for Multiple Interfaces

Why I Picked This Project

If I had to choose the project that stretched me the most during the internship, it would be Insighta Labs+.

Not because it was simply a large project.

Not because it used unfamiliar technologies.

But because it forced me to think beyond individual endpoints.

Across three stages and about 16 active days of implementation, I wasn't just building an API.

I was building a backend platform that needed to support:

A web application
A command-line interface (CLI)
Multiple user roles
Authentication and authorization
Search workflows
Data ingestion pipelines

Each stage built on the previous one.

This meant early architectural decisions became foundations for everything that came after.

The breaks between stages also gave time to review what was already built, identify weaknesses, and approach the next stage with a clearer understanding of the system.

This was where I started seeing the difference between writing backend code and engineering backend systems.

What It Was

Insighta Labs+ is a profile intelligence platform built around a shared backend architecture.

The platform supports:

GitHub OAuth authentication
Profile intelligence workflows
Role-based access control
CSV profile uploads
Search and filtering
Data export

The interesting part was not any single feature.

The challenge was ensuring every interface depended on the same backend rules.

A browser user and a CLI user should receive the same:

Authentication behavior
Authorization decisions
Data consistency
API responses

The backend had to become the single source of truth.

The Problem It Was Solving

One common problem in software systems is allowing different clients to slowly become different products.

The web application starts implementing its own logic.

The CLI starts duplicating behavior.

Authentication rules become inconsistent.

Eventually, nobody can confidently explain how the system actually works.

The goal with Insighta Labs+ was to prevent that.

The backend needed to own:

Business logic
Authentication
Authorization
Search behavior
Data access rules

Every client should consume the backend instead of recreating it.

How I Approached It

My approach was guided by one principle:

Every client should depend on the backend, not the other way around.

This affected every major decision.

Authentication Across Web and CLI

Supporting browser authentication was straightforward.

Supporting CLI authentication was more interesting.

The browser flow used traditional GitHub OAuth.

The CLI flow required PKCE (Proof Key for Code Exchange), allowing secure authentication without exposing client secrets.

The backend had to manage:

OAuth state
PKCE verification
Authorization code exchange
Callback validation
Session creation

A simple login feature became a system of interacting parts.

Secure Token Handling

I avoided storing raw tokens directly.

The system used:

Opaque access tokens
Refresh token rotation
Token hashing
Session lifecycle management

The goal was to make authentication secure while keeping the developer experience predictable.

Role-Based Authorization

The platform supported different user roles:

Analysts
Administrators

Instead of scattering permission checks throughout the application, authorization was handled centrally.

This made the system easier to maintain and reduced the chance of inconsistent access rules.

Natural Language Search

One of the most interesting parts was building deterministic search.

Instead of using AI models, I built a parser that could understand queries like:

"young males from Nigeria"

and convert them into structured filters.

The parser handled:

Gender detection
Age ranges
Country extraction
Validation

The goal wasn't to understand every possible sentence.

The goal was to understand expected user intent reliably.

Performance Improvements

As the system grew, repeated queries became expensive.

To improve efficiency, I introduced:

Query normalization
Cache key standardization
Response caching
Cache invalidation after updates

The challenge was not only making things faster.

It was making them faster without serving outdated information.

What Broke

A lot.

And that was where the real learning happened.

OAuth Complexity

OAuth becomes significantly harder when supporting multiple clients.

The browser flow and CLI flow introduced different requirements.

Small mistakes in:

Redirect URLs
State validation
Token exchange

could completely break authentication.

Search Edge Cases

Users rarely search exactly how developers expect.

Some queries created conflicting filters.

Others were ambiguous.

Instead of guessing, I made the parser fail clearly and predictably.

Cache Consistency

Caching solved performance issues.

But it introduced a new problem:

How do you know when cached data is no longer correct?

The solution was automatic cache invalidation after data mutations.

What I Took Away

Insighta Labs+ changed my mindset.

Before this project, I thought mainly in terms of features.

After it, I started thinking in terms of systems.

I learned:

Authentication is a system, not just a login endpoint.
Authorization is an architecture decision.
Caching is a consistency problem.
APIs become products when multiple clients depend on them.

Task 2: Funnel Display APIs — Building Features That Fit Existing Systems

Why I Picked This Project

Compared to Insighta Labs+, this task was smaller in scope and took about 3 days of focused implementation.

But it represented another important side of backend engineering.

In real-world teams, you rarely build everything from scratch.

Most of the time, you are extending an existing codebase.

The challenge is not just making your feature work.

The challenge is making it belong.

That is why I picked this project.

What It Was

The Funnel Display API was a backend feature built for SEIL to expose funnel and stage information required by the frontend.

The implementation introduced four authenticated endpoints:

Retrieve available funnels
Retrieve full funnel details
Retrieve stages for a funnel
Retrieve a specific stage

The work also included:

Database migration
Service logic
Controller implementation
Unit test updates
Swagger documentation

The Problem It Was Solving

The frontend needed a clean way to display funnel information.

Instead of exposing database structures directly, the backend needed to provide meaningful product-level data.

The API needed to answer questions like:

"Show this user's funnel."

"Show the stages inside this funnel."

"Show details about this specific stage."

The backend became the bridge between stored data and the user experience.

How I Approached It

Before writing code, I studied the existing architecture.

SEIL already had:

NestJS
TypeScript
PostgreSQL
JWT authentication
Repository-based data access
Swagger documentation

The goal wasn't to introduce a new style.

The goal was to follow the existing one.

Database Migration

The first step was adding the required database structures.

Instead of manually modifying the database, I created a migration.

This made schema changes:

Repeatable
Version controlled
Safe across environments

A database change is not just a database change.

It becomes part of the application lifecycle.

API Design

The endpoints were designed around frontend needs.

A frontend does not think:

"Return rows from the funnel table."

It thinks:

"Display this funnel and its progress."

That difference influenced the API structure.

The routes focused on:

User ownership
Authentication
Meaningful responses

Service Layer Design

I kept responsibilities separated.

Controllers handled:

Request handling
Validation
Responses

Services handled:

Business logic
Data retrieval
Rules

This made the feature easier to test and maintain.

Testing

I updated unit tests to verify funnel service behavior.

I also manually tested the endpoints through Swagger:

Start the development server
Authenticate with a JWT
Call each endpoint
Verify responses and status codes

The result was a frontend-ready API surface.

What Broke

The biggest challenge wasn't a failed build.

It was ensuring the feature matched the existing system.

A backend feature is not successful just because it works.

It should feel like it was always part of the application.

That meant paying attention to:

Existing patterns
Response formats
Error handling
Authentication rules

What I Took Away

This task taught me that backend engineering is also about integration.

I learned:

Migrations are part of feature development.
API design should reflect user actions.
Existing architecture deserves respect.
Good features fit naturally into systems.

Final Thoughts

These two projects represented two different sides of backend engineering.

Insighta Labs+ taught me how to build systems that evolve across multiple stages, interfaces, and requirements.

Funnel Display APIs taught me how to contribute to an existing system and extend it safely.

One required creating foundations that could support future growth.

The other required understanding an existing foundation and building on top of it.

Together, they reinforced a lesson I will carry forward:

A good backend engineer doesn't just write code. They understand the system they are changing and make that system better.