I work on web development while also creating and selling denim remake works under the name "Linora."
As I continued with handmade sales, I found myself needing to manage:
"How much did this piece cost to make?"
"How many materials do I have left right now?"
"Did this event actually make a profit?"
"I want to change prices between consignment sales and event sales"
At first, I managed everything using spreadsheets, but when materials, products, sales, and events were managed separately, it gradually became tedious.
That's when I thought:
I want a tool that consolidates all the management needed for handmade sales into one place
This was the beginning of the development.
At first, I had no plans to release it as a SaaS.
I simply wanted to create a tool that would be easy for me to use.
However, as I progressed with development and researched, I discovered that many handmade creators manage their work using Excel, spreadsheets, or handwritten notes.
"Wait, maybe this isn't just my problem?"
I started thinking this way, and midway through, I redesigned it with public release in mind.
A personal tool can be a bit rough and still work, but when other people are going to use it, you need to think about authentication, billing, account deletion, data protection, and error handling.
From that point on, it transformed from a "personal app" into "service development."
Linora Works primarily uses the following technologies:
- Next.js App Router
- TypeScript
- Prisma
- PostgreSQL
- Neon
- Clerk
- Stripe
- Vercel
I structured it so that frontend and backend are developed together with Next.js without separation.
Since this is personal development, I prioritized "not increasing the number of things to operate."
For the database, I use PostgreSQL and manage it on Neon.
I rely on Clerk for authentication and Stripe for payments.
Rather than building everything from scratch, I decided that delegating critical parts like authentication and payments to existing services has greater advantages in both security and development speed.
One of the core features of Linora Works is cost calculation.
It seems simple at first glance, but it turned out to be surprisingly complex once I started building it.
For example, if a product uses:
- Fabric: 30cm
- Hardware: 2 pieces
- Thread: 1m
I calculate the cost from the unit price of each material and the quantity used.
That much is straightforward.
However, in reality:
What if material prices change midway?
If fixed costs are included in the cost of goods, do I recalculate past sales?
If I edit product information after selling, how do I handle past profits?
These kinds of issues come up.
Especially with accounting and sales tools, if you recalculate based only on current settings, past figures change too.
For this reason, I adjusted the design so that fixed costs have history, ensuring that past numbers don't change later.
Rather than just "getting numbers,"
I was very conscious about whether the numbers would still make sense when looking back at them later
I also struggled with inventory management.
For example, if a product has 3 units in stock, but I register 5 units sold in the sales log:
Do I just make the inventory negative?
Do I reject the sales registration itself?
Do I just show a warning?
In Linora Works, if there's insufficient inventory, the registration is rejected and the app displays which products and quantities are short.
Rather than adding convenient features,
I prioritized preventing incorrect data from being created
These subtle behaviors were easier to imagine precisely because I actually do event sales myself.
I adopted Clerk for authentication.
Being able to skip self-implementing login, account creation, and session management is a huge help in personal development.
On the other hand, once you release as an actual service, there are many things the app side needs to consider:
Where to redirect after login
Account deletion
How to handle after cancellation
Linking users with Stripe
And so on.
Particularly, the cancellation process has this issue:
"Is it okay to delete everything the moment the account is deleted?"
In Linora Works, I synchronized Stripe's contract status with the app's user status, so data is retained for a while even after cancellation.
The price is 900 yen per month.
The first 31 days are free to use.
I use Stripe for payments.
When creating a billing service, you need to consider:
Checkout
Customer Portal
Webhooks
Subscription start
Cancellation
Payment failure
Subscription status
And so on.
Webhooks were particularly important.
When the contract status changes on Stripe, it must be correctly reflected in the app's database.
Even if it works in the test environment, I had to confirm multiple times right before release whether the production Secrets, Price IDs, and Webhook Secrets were set correctly.
Personally, I felt more "like I'm actually building a service" when working on the payment side than when building the UI.
Partway through development, I started operating with separate develop / staging / main branches.
In personal development, at first you might think:
"Maybe I can just push directly to main?"
But once billing and database migrations get involved, it becomes quite scary.
Particularly with Prisma migrations, I had to clarify:
Which environment it runs in
That it doesn't accidentally apply to the production database
How it executes during Vercel builds
Before the official release, I established a flow where I confirm everything in the staging environment before reflecting it to main.
This part was more of a lesson in operational design than in development itself.
It's hard to break your own app.
Since you know "if I click here, this happens," you unconsciously perform the correct operations.
So before release, I requested comprehensive testing from external testers.
The test cases ultimately numbered around 150-200.
I had them confirm all major features: material registration, product registration, inventory, sales, events, payments, and more.
Fortunately, no critical bugs were found, but
I was able to fix UI inconsistencies and subtle behaviors that I hadn't noticed myself.
Even in personal development, if you're releasing as a paid service, I think doing third-party testing was worth it.
"Alright, it's done,"
you think, but something always comes up until the last moment.
On the official release day itself, I received a bug report from a user about login issues.
When I investigated, it turned out that part of the login URL string was wrong.
It was a very simple mistake.
But the longer the development period, the more
small mistakes like this remain rather than complex logic issues.
Once I started receiving feedback directly from users after release, I finally felt the shift from "development" to "operations."
Official release on September 15, 2026.
On the first day, 4 people registered, and 2 of them even proceeded to payment registration with Stripe.
Of course, these aren't big numbers.
But a service that I alone conceived, designed, developed, tested, and released—actual users registered for it.
That was quite a thrilling experience.
A web app is just data and screens while you're coding.
It only becomes a "service" the moment someone starts using it.
What I realized from building Linora Works is:
In personal development, the hard part isn't just writing code.
Feature design
UI
Pricing
Terms of service
Payments
Testing
SEO
Landing page
Advertising
Customer inquiries
Release announcements
You do it all yourself.
You're a developer, designer, QA, marketer, and customer support all at once.
Conversely, that means
being able to build an entire service yourself
is the most interesting part of personal development.
Currently, the focus is on cost, inventory, and sales management, but I plan to add features going forward based on user feedback.
Candidates I'm considering include:
- Sales analysis using AI
- A feature to introduce creators to each other
- Team features for multiple users
- Review management
- SNS post suggestions
However, I don't want to make it a service that competes on feature count.
What I want most is for handmade creators to
"not spend time on management and focus on creation and sales"
Linora Works started from
"something I wanted,"
a very small reason.
But in personal development, maybe that's exactly the right way to start.
Since you're the user yourself, you understand what's frustrating.
You know what features are needed.
You notice what's hard to use.
And if other people feel the same problem, it has the potential to become a service.
Linora Works is still just beginning.
I want to nurture it little by little while listening to users' voices going forward.
