The Products We Build and Run Ourselves: A Map of the Yeowubie Portfolio

Why a Development Studio Builds Its Own Products

A development studio builds its own products for reasons unrelated to lengthening a list of credentials. Client projects end at delivery. Your own product begins at release. There is a kind of judgment that forms only when you personally absorb the cost of being wrong. Yeowubie Interaction builds and operates products to acquire that judgment.

A team that only takes contract work always stands on the receiving side of requirements. Someone else decided what to build, and when that decision misses, the client absorbs the loss. The development team has discharged its obligation simply by matching the specification. When this arrangement runs for years, the team gets better at reading specifications and no better at asking about what the specification left out.

Owning a product inverts that. The person who decides which feature goes in and the person who pays for that decision are the same person. Rejections in App Store and Play Store review. Adding one more locale and watching half the layout break. A user asking to have their own data corrected, and discovering that no procedure exists for receiving such a request at all. None of this appears in a planning document. It enters the list only after you have lived it.

This article maps the products Yeowubie operates into three problem areas. Reducing repeated record keeping is onSpots, an attendance management service. Connecting people to people is Langtori, a matching and mapping service for Korean language learning. Narrowing market information asymmetry is Job Connect VN, a recruitment service for the Vietnamese market. Alongside these is Winnie, a platform that helps small business owners in Vietnam run their stores and move into digital operations. Winnie carries enough material for its own article and has been written up separately, so it appears here only as one axis of the portfolio.

One thing up front. This article contains no user counts and no download figures. Usage metrics for our own products are still ahead of instrumentation work, so accurate values do not exist, and we do not manufacture plausible looking numbers. Instead we have written why each decision inside each product was made the way it was. When choosing a development partner, the information that actually discriminates is usually the reasoning behind a judgment rather than a performance figure.

Reducing Repeated Record Keeping: What Attendance Management Taught Us

Attendance management looks simple on a feature list. Clock in, clock out, done. Build it and run it, and the outcome turns on exceptions rather than on the record itself: lateness rulings, remote work requests, spoofed locations, and the final handoff to whoever runs payroll.

onSpots records arrival and departure with a single tap inside an office geofence. An administrator sees on one screen who is present, who arrived late, who is remote and who is out. Remote work and leave requests arrive inside the app, and approval or rejection happens in the same place. Company-wide announcements go out by push, and a monthly CSV export produces the attendance sheet used for payroll. The app runs in Korean, Vietnamese and English.

The first lesson is that rules differ by organization. What counts as the start of the working day, and how many minutes of slack still count as on time, are operated differently at every company. onSpots classifies late and on time automatically, but leaves the grace window used for that ruling open for the organization to set. Had we baked that value in as a constant, it would have broken at the second customer. In an internal operations tool, policy belongs in data, not in code.

The second lesson is that a record becomes useful only when it connects to a ruling. However precisely you accumulate raw logs, if the person computing payroll still reorganizes them by hand, that team's workload has not decreased; they have merely gained one more screen to check. So we treated the monthly export as the closing stretch of the product rather than an accessory feature. An internal tool is measured more accurately by how much manual work disappears behind the screen than by how polished the screen is.

The third lesson concerns spoofed locations. Apps that fake coordinates exist, and detecting them is not the hard part. The hard part comes after detection. Automatically invalidating a check-in also pushes people whose coordinates jumped on a weak signal into the absent column. onSpots chose to flag suspicious records and surface them to the administrator. This is not a machine ruling and a human being notified. It is a machine pointing and a human deciding. In a tool that touches people's attendance records, that difference is a question of trust.

The fourth lesson is that multiple languages are a premise rather than a feature. An organization working across Korea and Vietnam already contains members using different languages inside the same company. Treat language switching as an option bolted on later, and the sentences read every day, announcement text, approval reasons, status labels, get stranded one by one in their original language. Designing screens on the premise of three languages from the start is an entirely different job from layering translation on afterward.

One point for anyone commissioning an internal operations tool. A specification that records only what will be captured is half written. Write down who looks at what and presses what when a situation falls outside the rule, and you get a tool people actually use.

Connecting People to People: What Learning Matchmaking Taught Us

What learning matchmaking taught us is that the difficulty of connection lies in ordering conditions rather than in search. Langtori is a matching and mapping service between people who want to learn Korean and people who teach it. Yeowubie does not provide lessons. Teaching is done by the individual teachers and institutions on the platform, and what we build is the structure through which they find one another.

On Langtori a learner narrows down teachers by purpose. There are purpose categories such as conversation, grammar, TOPIK, business Korean and EPS-TOPIK, alongside categories covering other language exams including TOEIC, IELTS, TOEFL and OPIc. Customized matching works from region, level and learning goal, and lessons open both online and in person. Locations such as Hanoi and Thai Nguyen appear next to online availability, and the schedule and progress of booked lessons are managed on a single screen. Teachers can create their own lesson page and share it on social media, and profiles carry reviews and ratings left by learners. The platform supports Korean, Vietnamese and English locales, with Vietnamese as the primary one.

The first thing we learned is that a two-sided market is really two products. A screen that serves learners well and a screen that serves teachers well have different definitions of success. Learners want to narrow quickly to someone matching their conditions. Teachers want to express precisely what they are good at. Force both into one set of screens and neither side is served properly. It looks like one project on a quotation and has to be treated as two in design.

The second is that filters are a taxonomy design problem rather than an interface problem. A learner preparing for TOPIK and a learner preparing for EPS-TOPIK have different purposes and need different teachers. Collapse them into one bucket and match quality falls apart no matter how attractive the filter looks. Understanding the domain comes before drawing the screen. If a development partner never asks you to clarify the vocabulary of your domain, treat that as the first warning sign.

The third concerns mapping. Because lessons can run online, location seems irrelevant, and in practice it is not. For a learner who wants to meet in person, travel distance is a condition, and learners in the same area tend to share daily rhythms and learning purposes more closely. Matching with location stripped out looks tidy, but it removes one of the criteria people actually use when choosing.

The fourth is how initial supply is handled. In a matching service, if one side is empty, the other side's screen is blank however well it was built. Langtori dropped the premise that the platform must gather all supply itself and added a mechanism for teachers to create and distribute their own lesson pages. Each brings their own learners, and those learners then see other teachers as well. It is not a complete answer, but it works in practice in the early phase of a two-sided market.

One point for anyone considering a marketplace or matching service. If the specification says nothing about how initial supply will be filled, day one is a blank screen even with every feature complete. That item belongs in product design, not in the marketing plan.

Narrowing Information Asymmetry: What Job Matching Taught Us

What we set out to narrow in recruitment is information asymmetry. Job Connect VN connects Vietnamese talent who work in Korean with employers, and is scoped to the Vietnamese market. It does not stop at aggregating postings for browsing. The weight sits on letting an applicant see where their application currently stands.

The service runs around a job board that gathers open positions. Job seekers keep a profile and a CV in their account, and separately track the postings they have applied to and the ones they saved out of interest. The interface is built around Vietnamese, and the target market is limited to Vietnam.

The first lesson is that asymmetry does not run in one direction. A job seeker struggles to know what a company is actually like and whether the stated conditions will hold. An employer has no convenient way to confirm that an applicant's Korean is what the resume claims. Make it comfortable for only one side and the other leaves, after which the remaining side has nowhere to go. An intermediary service holds together only when the design reduces distrust on both sides at once.

The second lesson is that silence after applying is what drives people away. When nothing follows the apply button for long enough, people stop opening the service. The application history screen looks like an accessory feature and is in fact the stretch where the service keeps its credibility. Even when the outcome is unfavorable, simply seeing which stage you are at changes the experience substantially. We often see this screen pushed down the priority list on recruitment builds, and in our judgment the order is inverted.

The third lesson is that limiting the market is a design condition rather than a weakness. What goes on a resume, how job categories are divided, and which credentials genuinely carry weight in hiring all differ by market. Trying to hold several countries at once from the start produces a field structure that fits none of them. Narrow the target and you can shape fields to match that market's conventions precisely. Generality can be added later, while an inaccurate field structure is hard to fix once data has accumulated.

The fourth lesson is that how you hold a CV determines everything downstream. Accept CVs only as uploaded files and storage is simple, but the data is nearly useless for search and matching. Accept structured fields and entry becomes more tedious, while the number of things you can do with that data grows. Either way the decision is made in the first week and governs the following years. If a development partner treats such decisions as trivial implementation choices, the cost comes back large.

One point for anyone preparing a recruitment or intermediary service. Build the specification around the basic motions of posting a listing and receiving an application, and it will mostly fail to produce what you wanted. The mechanisms that make two sides trust each other have to appear as concrete items.

How Product Lessons Return to Client Projects

What remains from operating your own products is not reusable code but criteria for judgment: the habit of building multiple languages in as structure from the beginning, the habit of asking about exceptions at the specification stage, and the habit of putting post-release operating load into the quotation. Those three come back into client projects.

Start with languages. Handling Korean, Vietnamese and English across all three products confirmed repeatedly that extracting strings into files is not sufficient. Date order, name order, the composition of address fields, and number and currency formatting all differ by language. So do typefaces. The typeface chosen for Vietnamese screens carries no Hangul glyphs, so the moment Korean appears the text breaks. In Job Connect VN we solved this by layering in a Korean fallback font. Each such item is small on its own, and the initial design produced by a team that has been through them looks visibly different from one that has not.

Next is operating load. We handle store releases and review responses, push notification delivery, user inquiries and data correction requests for our own products ourselves. Because we know how much time those actually consume, we put that stretch into the quotation and the schedule on client projects too. There is a gap between the day development ends and the day a service settles, and leaving that gap out of the arithmetic simply means someone absorbs the cost unplanned.

The third is the direction of questioning. A team that has operated its own product asks about exceptions before it asks about features. What happens if the user cancels in this state. Where does the item queue if the approver is away. Who fixes incorrectly entered data, and on which screen. These questions make the first meeting somewhat longer and sharply reduce the number of times the specification has to be reopened mid-build. The experience of paying for those gaps out of your own pocket is what produces the question list.

Looking at the portfolio as a whole, the three branches converge on one axis. onSpots removes manual work from records repeated every day. Langtori helps scattered individuals find one another. Job Connect VN narrows the gap in what each side knows about the other. Winnie adds operating experience from the same lineage by helping small business owners in Vietnam run their stores and move into digital operations. Winnie carries enough material for its own article and has been written up separately.

Yeowubie Interaction is a development studio working across two locations, Korea and Vietnam. We build and operate our own products while carrying out development work for client companies. We do both because what is learned on one side is immediately usable on the other.

Finally, three questions for anyone in the position of choosing a development partner. First, if they operate a service of their own, ask what they learned was wrong from running it. If only favorable stories come back, they most likely are not really operating it. Second, ask who does what during the three months after release. A quotation with no prepared answer to this will grow later without exception. Third, watch whether they ask you to clarify the vocabulary of your domain. The party that digs into categories and exceptions turns out to cost less than the one that quotes immediately without asking anything.