Keep each product small enough to ship and support
As a solo builder, I needed products I could launch, support, and improve without creating a small enterprise platform.
Product studio case studyLive beta
A small web-product studio for useful free tools and low-cost personalized products for oddly specific moments.
I created the brand, product strategy, UX copy, visual system, and first working Click: Meeting Cost Ticker. I also defined a repeatable way to choose free and paid products while keeping each release small and complete.
Product strategyUX writingCreative directionNext.jsTypeScriptResponsive UI
In brief
The catalog uses a free-and-paid model
Free clicks are built for reach, screenshots, organic sharing, and repeat visits. Paid clicks are reserved for moments where personalization, urgency, gift value, or polished downloadable output creates a credible reason to pay.
Meeting Cost Ticker tests use and sharing. Instant Custom Crossword Gift tests whether personalization gives people a reason to buy.
Opportunity
Build small products without adding a platform
The goal was a repeatable studio model, not a pile of unrelated novelty tools.
Small products still need a quality bar
Each Click had to explain itself, work without onboarding, hold up on mobile, and include one memorable detail.
Decide what should be free and what is worth paying for
Free products test discovery and sharing. Paid products focus on personalization, urgency, gift value, or clear time savings.
Business model
Use free products for discovery. Charge when the value supports it
The user, buyer, and sharer may be different people. Pricing accounts for that.
Make free tools easy to try and share
Free products open immediately and support screenshots, sharing, repeat visits, and brand recall. A quick curiosity should not hit a paywall.
Charge when the value is clear
Paid products offer personalization, urgency, emotional value, or a polished download that saves the buyer time.
Product filter
Ask six questions before building a Click
- Who experiences the problem?
- Who would realistically pay?
- Who would realistically share it?
- What free or AI substitute already exists?
- How much work will it take to build and maintain?
- Should the value be free, paid, or an upsell?
First Click
Build the engine first, then add personality
The calculator worked before the mascot entered the room.
Studio homepage
The Lab launched with a working product instead of an empty brand page and a large roadmap.
Functional MVP
The first version handled meeting state, attendee groups, editable salary estimates, elapsed time, and live cost.
Delight pass
After the cost engine worked, I added the meeting-room scene, faceless attendees, light workplace humor, and Click asleep in the corner.
Live meeting
Users can change attendee groups while a meeting is running. Past cost remains intact while the updated team rate applies from that moment forward.
Strategic UX decisions
Small technical choices made the product easier to trust
Use local defaults instead of another dependency
The tool uses an editable local list of common U.S. job titles instead of a live salary API. This avoids latency, cost, rate limits, and another data dependency.
Keep the cost accurate when attendance changes
People join late and leave early. The app keeps the cost already accrued, then applies the new team rate from that point forward.
Keep salary data in the browser
Meeting names, salary estimates, attendee counts, and totals stay in the browser. Users can start, download the result, and leave without an account.
Stop forgotten meetings after eight hours
The meeting ends after eight hours. This limits runaway totals without saved sessions or account infrastructure.
UX writing
Lead with the task. Add personality where it helps
The copy answers questions and introduces the studio without adding a sign-up gate.
Explain the product before adding the joke
The page first explains the tool. The line “Every second counts. Literally.” adds personality after the task is clear.
Answer likely questions early
Copy about editable salaries, browser-only data, and the eight-hour limit answers common questions before they block use.
Let the free tool introduce the studio
The mascot, screenshots, and branded receipt introduce the studio without asking for an email address or sign-up.
Mobile
Give mobile users a clear sequence
On narrow screens, setup, live cost, and completion follow a vertical, tap-friendly flow.
Attendee setup
Live ticker
Meeting summary
Downloadable artifact
End with a useful receipt
The browser creates a PNG that users can save or share. The receipt also carries the Lab identity beyond the site. It is legible and functional, with a visual refinement pass planned after launch.
Technical snapshot
Use simple architecture and spend the effort on the experience
Next.js + React
TypeScript
Tailwind CSS
Client-side only
None
Editable local defaults
Browser-generated PNG
Netlify
Release scope
The first release tests the core behavior
These features were not needed to learn whether people would use and share the core product.
Deferred
User accounts
Deferred
Saved meeting history
Deferred
Team dashboards
Deferred
Organization-level reporting
Deferred
Live payroll integrations
Deferred
Real-time salary APIs
Deferred
Persistent share links
Deferred
Subscription billing
Launch-stage validation
Observe use before expanding the product
There are no performance or conversion claims yet. The current release works, costs little to maintain, and can inform the next product decision.
- Do visitors start a meeting or leave after reading the concept?
- Do people add realistic attendee groups or only test the novelty?
- Do users download the receipt?
- Do screenshots or links get shared organically?
- Does the free product lead visitors to explore the studio or return later?
- Which UX details create confusion on real devices?
Nice Little Click Lab shows how I define an audience, choose a fair price, keep the architecture small, ship a useful product, and use real behavior to decide what comes next.