Aily Kang
한국어

Menu

Designing since 2013

Vague requests,turned into services that actually run.

“Something roughly like this — could you do it?”
That is how most of them began.

No plan? I build the structure. No screens? I draw them. It needs features, an admin, a server — I do those too.

I do whatever it takes to keep the service running all the way through.

The title doesn't matter much. I'm the one still there when the idea becomes a service. That's the job.

Explore selected work
ResumeEmailGitHub ↗

All case studies

The decisions, and what they cost

Showing 6 of 18 case studies

More live websites

Some have been operated by the client since handover, so the content may have moved on.

Approach and background

Some costs simply disappear when one person owns it.

What you stop paying for

Some costs simply disappear when one person owns it.

3 vendors1 person

No handoffs

Whoever draws the concept writes the markup and builds the front-end. Nothing leaks in between.

Endless revisionsA choice of two

The revision loop ends

Where several people sign off, I present two directions from the start. It becomes a decision, not a correction.

Calling a developer to change a sentenceThe operator edits it

Post-launch cost drops

Most maintenance requests were never bugs — they were copy changes. So the admin gets built for that.

The order never changes.

How I work

The order never changes.

The technology changed on every project. The sequence never did.

This is usually how it starts.
01

“Could you maybe build something like this?”

There is no spec.

There is, however, an idea.

02

That is where my work begins.

I turn the story in someone's head into a structure,

and the structure into screens.

03

This is where it becomes real.

Design, code, admin, server.

One at a time, in whatever order it needs.

04

Then I let go of it.

It has to still make sense to me a year later.

If it does, somebody else can pick it up too.

STAGE 01

I start by understanding.

Almost no project has arrived with a complete specification.

I gather everything — spreadsheets, slide decks, chat threads, phone calls — and work out what is actually being built.

What I don't know, I confirm rather than assume.

STAGE 02

I build it myself.

Whoever drew the concept writes the markup and builds the front-end. Same person.

No handoff means nobody ever says “this isn't what the design showed”.

STAGE 03

I look six months ahead first.

API keys stay on the server, never in the app.

Anything I expect to swap out later gets an interface now.

A service is used far longer than it is built.

STAGE 04

I use it, then cut it back.

Building it myself doesn't make it safe from me.

Two weeks of real use, then anything unused comes out.

Knowing what to drop is harder than shipping more.

I redesign the sequence of the work, not just bolt a tool on top.

AX · Transforming how work runs

I redesign the sequence of the work, not just bolt a tool on top.

Automation comes last. First I turn the places people were filling in with judgement into written rules, then make those rules verifiable — and only then attach a tool. That is what lets the work keep running after whoever built the tool has gone.

01

Find where the human hands actually are

As sales channels multiplied, the options and prices for the same product drifted apart. Checking which value was correct meant a person opening every screen and comparing by eye.

Notation differed per channel, so even deciding whether two listings were the same product was the first problem. I normalised option combinations into signatures — only then was there a unit a machine could compare.

41,067 raw option rows → 11,444 distinct option axes

02

Turn judgement into rules

Prices that diverged depending on who handled them became a documented pricing rule. The point is to move the decision from the person to the rule.

I separated diagnosis and correction planning from execution: what changes and why is produced first, reviewed, and only then run. That is how you stop automation from being quietly wrong.

0 unregistered axes on re-comparison after migration

03

Hand the tool over and step away

The automation ships as an executable, so non-developer operators register products and change prices themselves without going through a developer.

A tool only I can run isn't a transformation — it's a new bottleneck. Making it handover-ready is part of the job, not an extra.

PyInstaller packaging · run by operators directly

AI gets the rulebook first

Before handing a codebase to an AI agent I define the naming, CSS variables, breakpoints, prohibited patterns and documentation procedure. That is how I take the speed without losing the quality bar.

Every number here comes from an actual deliverable. I have left out any saving or ROI figure I could not verify.

The surviving archive

205, and the ones I lost count of

This isn't about the number.It's about meeting the same problem 200-odd times.

Some got one website. Some I've been fixing alongside for years.

205 counts only the work I still hold files for. Plenty of the early jobs were never archived at all.

Wildly different industries, almost identical sticking points.

The admin is awkward. Plenty of features, none of them usable.

At some point I started looking at the structure before the features.

Sectors

Public sector & municipal portals5
Healthcare, hospitals & clinics12
Manufacturing, industry & construction34
Commerce & online stores26
Education & research18
F&B & franchises15
Associations & nonprofits14
Beauty & wellness13
IT & services22
Other46

Client names are withheld. The sector split is my own rough grouping of what survives in the archive, not an audit.

Things I kept running into

If the operator can't fix it, they end up calling me again.

Most maintenance requests weren't bugs. They were “could you just change this one sentence?”

So the admin kept shifting toward what an operator finds easy, not what a developer finds easy.

I present two concepts, never one.

Public bodies and associations have several people signing off.

One concept gets you revisions. Two concepts get you a decision.

Legacy code gets read before it gets changed.

I inherited a lot of Gnuboard, Youngcart and ageing PHP projects.

Editing before understanding the structure almost always broke something elsewhere.

So even now, on day one I barely touch the code.

A concept that survives the build beats a pretty one.

I watched too many handed-off designs come out half-degraded.

So I took the markup back.

From the logo to the server, same person.

Scope

From the logo to the server, same person.

For one client I've drawn the logo, laid out the catalogue, printed the banner, built the site and pushed it live.

So the brand on the business card and the brand on the website don't look like two different companies.

Brand

  • CI and BI
  • Logo design
  • Brand guidelines
  • Business cards, envelopes, stationery

Print

  • Catalogues
  • Product spec sheets
  • Leaflets and brochures
  • Posters
  • Banners and signage
  • Exhibition booths and panels

Campaign

  • University 60th-anniversary programme
  • International conferences
  • Election campaigns
  • School promotional material

Motion

  • After Effects motion graphics
  • Social content
  • Short-form video

Web

  • Responsive websites
  • Online stores
  • Admin systems
  • Server setup and migration

Automation

  • Crawlers and collectors
  • Workflow automation
  • Desktop applications
  • AI workflows

Contact

It's fine if it isn't figured out yet.

That's how most of them started.

Tell me why you want it before you tell me what it is.

I'll reply by separating what I can take on from what I can't.

kjyhopekr@gmail.com
GitHub ↗Resume

Open to roles in Korea, contract work, and remote projects internationally.
I usually reply within 24 hours.