DEV Community: Sangyoon Lee

The client asked for "one more thing" again. So I built ScopeSloth to answer.

Sangyoon Lee — Tue, 20 Oct 2026 06:54:27 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

ScopeSloth answers the client message you dread: the one that says "looks great, just a few small things" and then lists five.

You paste what you agreed (scope, rate, revision rounds) and the client's latest message. An agent lists every separate request. A second agent searches your agreement for each one and cites the line that covers it. Then plain code, not the model, decides the money: hours times the rate in your agreement, and whether a design tweak uses up one of your included revision rounds. A third agent drafts a calm reply: what is covered, what is an add-on and its exact price, and one question for anything unclear.

Who it is for: freelancers who have a written scope and still end up doing extra work for free, because arguing about it feels worse than doing it. The lazy move here is not to skip the work. It is to not have the argument.

Demo

Live: https://scopesloth.sellerkit.workers.dev

Click Load a sample (a made-up bakery website and a made-up client message), then Sort the requests. A run took 5 to 10 seconds in my tests.

The header photo and logo tweaks are revisions, so they are free and use one of the two included rounds. The ordering page, Instagram feed and PDF menu are not in the agreement, so they get a price.

The reply only contains amounts the code computed. If the model invents $400, the draft goes back with the exact problem.

Code

https://gitlab.com/globalmatchhub/scopesloth (MIT)

How I Built It

Stack: a Mastra workflow on Cloudflare Workers, calling open-weight models on Workers AI.

Models: gpt-oss-20b (Apache 2.0) is the default, reasoning effort low. Llama 4 Scout 17B is the second choice and the backup writer.
Workflow: createWorkflow(...).then(listRequests).then(checkScope).then(writeReply).
One tool: the checker agent has search_scope. It takes several queries at once and returns numbered agreement lines (S3). A cited line only counts if search_scope really returned it in this run. A request marked "in scope" with no valid citation becomes "unclear".
Small models answer in lines, not JSON. #2 extra - | new | 3 | not in the list is parsed by code, with a fallback when parsing fails.
Three checks, one vote. The checker runs three times in parallel. Code keeps the verdict most checks agree on and the median of their hours, and the page shows "2/3 checks agree" next to each request. A tie with no "in scope" vote counts as extra work; a tie that involves "in scope" stays unclear.
The rules are plain JavaScript (src/scope.js and src/parse.js, 19 tests, no model):
- rate and revision rounds are read from the agreement text ($60/hour, 2 rounds of revisions)
- hours from the model are clamped to halves between 0.5 and 40, so one wild guess cannot become a huge line item
- price = hours x rate, always computed in code
- a change to delivered work uses a revision round, and becomes billable only when the rounds run out
- the reply may only contain amounts the code computed, and must price every extra item
- no dashes, placeholders or phrases like "as per our contract" or "unfortunately"

What broke on the way

I ran the sample on the deployed Worker and read what came back.

Problem	What I changed
"Move the logo a bit to the left" was priced as $30 extra work. It is a design tweak, and two revision rounds were included.	Code decides "change vs new" from the request's words and overrides the model. A tweak is free while rounds remain, and billed once they are used up (tested both ways).
The model labelled "add an Instagram feed" as a change to delivered work	The same override: build words (add, feed, payment, PDF) force "new"
One run answered for only some of the requests, so the rest showed "unclear"	The missing numbers are asked again, once
A request the agreement says nothing about came back "unclear"	Silence in the agreement means extra work. Code turns it into extra if no line was cited and no line is close
Draft replies came with a non-breaking hyphen in "add-on"	`undash` normalises it
One check often came back empty: the model put an arrow (`extra -> new`) where the format has a pipe, copied from the "or ->" in my own format line, and the parser threw the line away	The parser reads the arrow as a pipe (tested), and the format line no longer contains an arrow
The same sample gave totals from $360 to $840 over 11 runs, because each run took one model guess per request	The scope check now runs three times in parallel. Code keeps the majority verdict and the median hours, and shows "2/3 checks agree" next to each request

Honest numbers

19 tests for the plain-code rules, run with node --test.
Deployed runs: 5 to 10 seconds, with slow outliers up to 32 s when Workers AI queued my request.
About $0.0009 to $0.001 per run at Workers AI list prices (5 model calls: one list, three checks, one reply; around 3,300 tokens in, 1,000 out).
Before the three-check vote, the same sample gave $360 to $840 over 11 runs. After it, 10 runs on a copy of the sample: 8 between $300 and $480, and 2 where the model called the ordering page or all three new requests "unclear" ($90 and $0), so the reply asked questions instead of quoting. The vote narrows the spread; it does not remove it. The hour estimates are still the model's guess, so the page tells you to adjust them. The money rules and the revision rule never varied.
"Load a sample" followed by "Sort the requests" returns a stored answer, so everyone sees the same result for the made-up bakery. Only an answer where every request was decided by at least two of the three checks is stored. Text you paste yourself is never stored.

Why Does Open Innovation Matter?

A client's message and a signed agreement are private. With an open-weight model on Workers AI the text is used for one request and not stored by my app, and anyone can read the code, run the same model on their own machine or swap it. The part that matters most is that the open pieces are swappable: the writing step has a backup, so if gpt-oss-20b returns an empty draft, Llama 4 Scout writes it instead, which is one line of config (that path did not trigger in my sample runs). A run costs a fraction of a cent, so a freelancer can use it on every message and never think about a subscription.

My Agent Session

Not embedded. The code and the table of what broke are above.

The Lazy Payoff

For the sample message, the by-hand version is reading the agreement again, deciding per request, estimating hours, doing the arithmetic, and writing a reply that is firm without sounding cold. ScopeSloth does that in under ten seconds, and the part that is most tempting to fudge, the arithmetic, is not left to a model. I have not measured this with real clients this week, so I am not going to claim a time saving beyond the sample.

Prize Categories

Best Use of Mastra: a three-step Mastra workflow with a Mastra tool (search_scope) and Mastra agents on open-weight models.

Code and English text were produced by an AI coding agent (Claude Code) working under my direction. I chose the topic, reviewed the results and published the post.

My last 38 cover letters all said something my resume didn't. So I built HonestFit.

Sangyoon Lee — Fri, 16 Oct 2026 02:24:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

HonestFit writes a short cover letter that only says what your resume can back up.

You paste your resume and a job posting. One agent reads the posting and lists the requirements. A second agent searches your resume for proof of each one and cites the exact line. A third writes the letter. Then plain code, not the model, checks every technology, every number and every "led / managed / architected" word in the letter against your resume. Anything it cannot find goes back to the model with the exact sentence, up to three drafts. A must-have you don't have gets one honest sentence instead of silence.

Who would pay for it: people who apply for jobs in a second language. AI writing tools are very good at fluent English and not very good at staying inside the facts. When English isn't your first language, you can't always tell when a smooth sentence has quietly turned "used Docker" into "led platform migrations". A recruiter reads your letter and your resume side by side. If they don't match, the fluent letter hurts you.

I would pay a few dollars a month for this. I know because I'm the first user (more below).

Demo

Live: https://honestfit.sellerkit.workers.dev

Click Load a sample to fill in a made-up candidate and a made-up posting, then Check fit and write. A run takes about 7 to 10 seconds.

Every requirement gets covered, partly or missing, with the resume line (L6) or your own note (N1) as proof. The sample candidate has never used Kubernetes or Go, so those stay missing. The model is not allowed to argue its way out of that.

The letter only uses what the table proved, and it admits the Kubernetes gap in one sentence.

Code

https://gitlab.com/globalmatchhub/honestfit (MIT)

How I Built It

Stack: a Mastra workflow on Cloudflare Workers, calling open-weight models on Workers AI.

Models: gpt-oss-20b (Apache 2.0) is the default, with reasoning effort set to low. Llama 4 Scout 17B is the second choice, and also the backup writer.
Workflow: createWorkflow(...).then(readPosting).then(matchEvidence).then(writeLetter).
One tool: the matcher agent has search_resume. It takes several queries at once and returns numbered resume lines. A cited line only counts if search_resume actually returned it during this run, so the model can't cite a line it imagined.
The checks are plain JavaScript (about 200 lines, 18 tests), with no model involved:
- Technology names, with aliases, so k8s = Kubernetes and Postgres = PostgreSQL.
- Numbers, compared by value: 120k = 120,000, seven = 7.
- Role words: led, managed, architected, head of and so on. They're only allowed if your resume already uses them.
- Em dashes, buzzwords and placeholders like [Your Name].
- Must-haves the letter ignores.
- A sentence like "I have not used Kubernetes yet" is treated as an honest gap, not a claim.

What broke on the way

Problem	What I changed
Small models often broke the JSON schema for structured output	Agents answer in a line format (`MUST: ...`, `#3 covered L6 \
gpt-oss sometimes returned an empty letter (it spent its tokens reasoning)	{% raw %}`reasoning_effort: "low"` and a bigger token budget. If a draft is still empty, Llama 4 Scout writes it instead.
"Node.js" split a sentence at the dot and caused false flags	Sentences only split before a capital letter
"120,000 users" was flagged against "120k users"	Numbers are compared by value
A draft said "I have led backend teams". Nothing caught it	The role-word check
On my real resume, "SQL and NoSQL databases" came out missing: the resume says MySQL, PostgreSQL and Redis, never "SQL". The letter then admitted a gap I don't have	Category words now expand to the products resumes actually name (SQL to MySQL/PostgreSQL, NoSQL to Redis/MongoDB, cloud to AWS/GCP...)

Measured on the sample (October 15):

gpt-oss-20b: 7 to 9 seconds per letter, 4 to 5 model calls, about 3,000 input tokens and 800 output tokens. That is under $0.001 per letter at Workers AI list price.
Every gpt-oss letter admitted the Kubernetes gap.
Some runs end with one flagged claim. The page shows it as a warning instead of hiding it.
Llama 4 Scout took about 30 seconds and left more issues, so gpt-oss is the default.

Known limit: the checker knows technologies, numbers and role words. Adjectives still get through: one draft called a service "high-availability", and the resume never says that.

Why Does Open Innovation Matter?

The price makes the side hustle work. Under a tenth of a cent per letter means $4 a month can cover heavy use with almost all of it as margin. At typical closed frontier-model prices, the same run with retries costs roughly 10 to 20 times more per letter.
I can swap models per step. Reading and searching use gpt-oss. When it returns an empty draft, Llama 4 Scout writes it. That fallback is one line of code, because both are open-weight models behind the same interface.
The model is not the judge. Open weights let me choose small, cheap models on purpose and put the trust in code I can read and test. With a closed API I'd be paying more to trust the model more, which is the opposite of what this tool needs.
Your resume could stay on your machine. The same weights run locally. I haven't built that mode yet (my 2019 Intel laptop can't run gpt-oss-20b at a usable speed), so for now the page sends your text only for the length of one request and stores nothing.

My First User

Me.

I'm a full-stack developer in Korea. I write English through AI translation, and I apply to remote jobs where I can work in writing. Before I built this, I had sent 38 cover letters. I ran HonestFit's checker over all 38 against my own resume:

38 of 38 said "13 years". My resume says "12 years 8 months".
27 quoted numbers from side projects, like "90 of 94 MCP servers scanned" or "13 marketplace extensions", that don't appear anywhere on my resume.
3 named a technology my resume never mentions.

None of it was a lie. But a recruiter holding both pages sees two slightly different people, and I had no idea until the checker showed me.

Then I ran the full workflow with my real resume against a real Senior Backend posting from my job search (its requirements list). The first run marked "SQL and NoSQL databases" as missing and wrote that I had no database experience, which is wrong (that bug is in the table above). After the fix: 5 covered, 2 partly, 1 missing (working across time zones), one draft, 6.9 seconds, $0.0008.

Did I pay? I'm the user, so no. But I would.

Prize Categories

Best Use of Mastra: the whole thing is a Mastra workflow with three agents and a tool, running on Cloudflare Workers.

Code and English text were produced by an AI coding agent (Claude Code) working under my direction. The resume data, the 38 letters and the decision to publish are mine. I write in Korean.

Figma plugin UI has a null origin: how I read a Google Sheet without a server or API key

Sangyoon Lee — Thu, 15 Oct 2026 02:27:40 +0000

I was building a Figma plugin that pulls rows from a public Google Sheet. It looked easy: fetch the CSV, parse it, done. It did not work, and the reason is easy to miss.

The problem

A Figma plugin UI runs in an iframe with a null origin. The Figma docs say this means the plugin can only call APIs that return Access-Control-Allow-Origin: *.

I built a sandboxed iframe with a null origin and tested each way to read the sheet.

Path	Result
docs.google.com gviz/tq?tqx=out:csv	blocked
docs.google.com export?format=csv	blocked
sheets.googleapis.com v4	works, but needs an API key
gviz/tq?tqx=out:json;responseHandler:cb loaded with a script tag	works, no key, no server

Why the export URL fails

The final response of the export URL does have the allow header. But the first answer is a 307 redirect, and that redirect has no allow header. The browser checks the first one and stops.

What worked

A script tag is not subject to CORS. So I ask Google for the JSON-with-callback format and load it as a script:

window.cb = (data) => { /* data.table.rows */ };
const s = document.createElement("script");
s.src = "https://docs.google.com/spreadsheets/d/<ID>/gviz/tq?tqx=out:json;responseHandler:cb&headers=0";
document.body.appendChild(s);

Add headers=0, otherwise Google guesses which row is the header and may eat your first data row.

Lesson

Before writing any code that reads someone else's API from a browser extension or plugin, check with curl whether the API sends Access-Control-Allow-Origin: *. If there is a redirect, look at the headers of the first response, not the last one.

The built-in browser pane of my tool could not run nested sandbox iframes, so I had to do this test in a real Chrome. Testing in the real environment saved me from shipping a plugin that fails on first load.

Have you hit a null-origin problem in another plugin platform, and how did you get around it?

I'm a full-stack developer, 13 years, based in Korea (UTC+9). I work in writing only, and use AI translation, so my English is simple. CV: https://cv.namubase.com

Available for remote contract work: 13-year full-stack dev (billing, admin, payments)

Sangyoon Lee — Wed, 07 Oct 2026 00:10:56 +0000

I'm Sangyoon Lee, a full-stack developer in Seoul with 13 years of experience, and I'm available for remote contract work starting now.

A note up front: I don't speak English well. I communicate in writing and use AI translation for every message, so please expect written replies (within 24 hours, weekends included), not calls or video.

What I build and fix

Admin dashboards and back-office tools (members, orders, settlement, permissions, change history)
Billing, settlement and payment integrations (PG, recurring payments, kiosk/card terminals)
Backends for web and mobile apps, plus Flutter apps shipped to iOS and Android
Stack: Laravel and CodeIgniter, Spring Boot, Node.js/TypeScript, React, Vue, MySQL/PostgreSQL/Redis, AWS, Docker

Things you can check

I replaced a production app's backend (serverless to Spring Boot WebFlux) without forcing a user app update.
I built a multi-channel settlement reconciliation engine (Java 17, idempotent reprocessing, rollback).
I shipped three new services in two months as the only developer, all on schedule.

How I work
Remote only. Scope and acceptance criteria are agreed in a document before I start, progress is written up every week, and I reply within 24 hours, weekends included. Everything stays in writing, so nothing gets lost.

Instead of an interview, the first small task is free
We agree on the scope in writing first (up to about 10 hours of work), and I deliver within a week with a short written update every day. If you like the result, we continue on a paid basis. If not, you've lost nothing. One free task per company.

If you have a backend, admin or integration task that keeps slipping, send me a short description and I'll reply with a plan.

Portfolio: https://cv.namubase.com

I ran my own SEO checker on my own sites. It called every Korean page "thin"

Sangyoon Lee — Mon, 05 Oct 2026 07:57:54 +0000

I built SearchLink, a small tool that checks a web page for SEO problems. A few weeks ago I ran it on my own 21 sites as a QA pass. All 21 answered with 200 OK, but the checker itself had three bugs.

1. Korean pages were marked "not enough text".
It counted words by splitting on spaces. Korean, Chinese and Japanese don't work like that, so a full Korean page looked almost empty. Fix: for CJK text, count every 2 characters as one word.

2. Title and description limits were English only.
Korean characters are wider, so they get cut off in search results earlier. I split the limits: 33 characters for titles and 85 for descriptions when the page is Korean.

3. It nagged pages I hid on purpose.
If a page is noindex or blocked by robots.txt, the checker now just says "hidden on purpose" and stops scoring it.

What I took from this: the best test data was my own real sites, in my own language. English samples would never have shown me bug #1. After the fixes, 110 tests on the paid build and 18 on the free build pass.

If you build anything that reads text, try it on a language that doesn't use spaces. It is a cheap way to find assumptions you didn't know you had.

About me: full-stack developer in South Korea, 13 years, open to remote contracts. I work fully in writing (async), so everything stays documented.
CV: https://cv.namubase.com
SearchLink: https://searchlink.namubase.com

I ship backends alone, in writing: 12 years, 6 products live right now

Sangyoon Lee — Fri, 25 Sep 2026 00:38:29 +0000

I am Lee Sangyoon, a full-stack engineer in South Korea. Twelve years, mostly in small teams where one person takes a feature from the spec to production and then answers for it afterwards. I am open to remote contract work and remote roles.

One condition, stated first so nobody wastes time: I work in writing only. Email, chat, issue trackers, pull requests. No calls, no video interviews. If that rules me out, it rules me out early, and that is fair to both sides. What I offer in exchange is a written trail of every decision, an answer within 24 hours, and a plan you can read before you pay for anything.

And the written trail is the part I would keep even if calls were easy. Every request you make and every answer I give stays on the record. A change of scope and what it costs is written down the moment it is agreed, so it is not a memory contest three weeks later. You can search the whole history of the project, and hand it to whoever takes over from you. In my experience most disputes in contract work start with "but we said" about something nobody wrote down.

Work I was paid for

Children's news app (Flutter, iOS and Android), 2024 to 2026. Shipped to both stores. Then rebuilt the backend from AWS Amplify to Spring Boot WebFlux while the app was live, as the only engineer. Because the API boundary was GraphQL, the app shipped no forced update during the migration. Recurring subscription billing through a payment gateway, Google and Apple sign-in, refresh-token auth. After launch: realtime ratings over GraphQL subscriptions, streak rewards, article translation.

Unmanned study cafe system, 2023. The whole thing: web seat booking and passes, an Electron kiosk in the store, an admin for both, card payment with recurring billing, and a door controller wired to pass state so access reflects payment in realtime.

Healthcare platform, 2020 to 2023. Rebuilt a hospital, patient and operator platform on Laravel 8 API plus React. Three role boundaries and SSO, API documented in Swagger so the app team could work in parallel, AWS setup and deploys run by me.

Realtime chat app, 2019 to 2020. Flutter and Firebase, FCM push, SMS-verified signup, in-app purchase with server-side receipt validation. Scaled from one server to four when traffic outgrew the box.

Before that, 2014 to 2019. A gold trading platform and its app, realtime chat and browser games, an eCRF solution for academic conferences, public sector sites, and a lot of commerce builds. PHP, jQuery and the habit of running my own servers came from here.

Side projects, all live, all built and operated solo

SearchLink (https://searchlink.namubase.com). Connects Google Search Console to Claude and ChatGPT over MCP, mails a weekly report with three things to fix, and alerts when clicks drop. Cloudflare Workers, D1, OAuth, billing.
Public auction price statistics site. A daily cron pulls a government open API and generates about 350 statistics pages. Workers plus D1.
Atlassian Marketplace apps. A Jira markdown editor and dashboard gadgets, through Atlassian's security review and publicly installable. Forge and React.
Marketplace extensions published on WordPress.org, JetBrains, VS Code, Figma and Wix.
Open source. An MCP server for Search Console on npm, listed in several MCP directories.

Stack

TypeScript and Node, Python, PHP and Laravel, Java and Spring Boot (WebFlux), React, Next.js, Vue, Flutter, React Native, Electron. PostgreSQL, MySQL, Redis, SQLite, D1. AWS, Cloudflare Workers, Docker, Nginx, Linux. GraphQL and REST. Payment gateways, in-app purchase receipt validation, social login, FCM.

What I am looking for

Remote contract work or a remote role, backend or full-stack, with written communication. Data pipelines, API integrations, LLM-backed tooling and "this thing must keep running unattended" work are what I enjoy most and what I am fastest at.

Reach me at globalmatchhub@gmail.com. Tell me what is broken or what you want built, and you will get a written plan back, not a meeting invite.

Why your Search Console API impressions don't match the UI

Sangyoon Lee — Mon, 21 Sep 2026 04:38:18 +0000

I was building a small tool that pulls Google Search Console data into Claude, and the first thing that broke was trust. My impressions total was higher than the number in the Search Console UI. Not by a rounding error. Noticeably higher.

Here is what was going on, in case you hit the same thing.

The mistake: summing page rows

The obvious way to get totals is to query by page, then add up clicks and impressions across all rows.

Clicks come out close. Impressions do not.

The reason: Search Console counts impressions differently depending on how you group the data. Grouped by property, one results page counts once. Grouped by page, every one of your URLs on that results page gets its own impression. If two of your pages show up for the same search, that is one impression for the site but two when you add up the page rows.

The fix: take totals from the date dimension

If you want numbers that match the UI, query with dimensions: ["date"] and sum those rows instead. Each day is counted once at the property level, so impressions line up with what Search Console shows.

{
  "startDate": "2026-08-24",
  "endDate": "2026-09-20",
  "dimensions": ["date"]
}

Use page or query dimensions for breakdowns ("which pages lost clicks"), and the date dimension for the headline totals. Don't mix the two in the same number.

Two smaller gotchas

Data lag. The most recent two or three days are usually incomplete. If you compare "last 7 days" to "the 7 before", end both ranges a few days back, or the latest week always looks worse than it is.
Average position is not additive. You can't take a plain average of the position column across rows. Weight it by impressions, or take it from the same date-level query.

What I ended up building

I wrapped this into a small MCP server so I can ask Claude or Cursor things like "which pages lost clicks this month" without exporting a CSV first. It is read-only, runs locally, and takes totals from the date dimension.

Disclosure: I built it. It's free and MIT: https://go.namubase.com/slite?s=devto-0921

If you've found other places where the API and the UI disagree, I'd like to hear them.