Aily Kang / makes services run
한국어

Designing since 2013 · 205 clients still in the archive

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.

Some people only design. Some people only develop.
I do whatever it takes to keep the service running all the way through.

I have worked this way since 2013.205 clients, counting only what I still have.More of them I kept fixing for years than I delivered once and closed.

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

See the case studiesResumeEmail meGitHub
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.

Running right now

Faster than any description: open them.

These are live. Click through and judge for yourself.

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

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.

How I work

The order never changes.

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

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.

Case studies

The decisions, and what they cost

What I chose matters more than what I made. Each case ends with what I didn't manage to do.

Flagship2026

Public childcare support portal

A public service should be easy to run, too.

I designed and built the front-end around one goal: staff should be able to manage the content themselves without calling a developer every time.

디자인퍼블리싱프론트엔드
See what I had to weigh up →
2026

Opportunity OS

I wanted something that tells you before you search.

More people miss public funding programmes than find them.

So I designed it to recommend first when you match the criteria, rather than to be searched.

FlutterPythonFirebase
See how it was built →
2026

EXITO Supply Collector

Copying the data took longer than listing the product.

Every supplier site is structured differently, so the operator repeats the same work forever.

I built a tool where you paste one URL and it pulls in as much of the product data as it can.

PythonPlaywright
See why it works this way →
2026

Office chair product page

Ask if AI made it, and I'll start with what it wasn't allowed to make.

There was no photography budget. The product still wasn't generated.

Real cut-outs stayed; only atmosphere was generated, with three colourways locked to one model and one light.

아트디렉션생성형 AIHTML
See where the line was drawn →
2021

Manufacturer catalogue and website

People read the catalogue, then visit the site.

Split print and web between suppliers and one company starts looking like two brands.

I prepared the product imagery once for both, and set colour from print — the side you can't undo.

카탈로그웹디자인퍼블리싱
See why print came first →
2016~

Commerce operations systems

Almost nothing was ever built once and finished.

Settlement, tax invoicing, points, orders, member management.

These are systems I kept fixing and extending across several years of live operation.

PHPMySQL
See what operating them taught me →
2026

Content Factory

I'm building the system before the writing.

So that nobody has to sit down and ask “what do I write today?”,

I'm designing it to automate everything from topic selection through to analysis.

AI WorkflowNode.js
See what's still in progress →

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.

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.comGitHubResume

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