Overview
More than a coding experiment.
Maker Forge helps makers and small product businesses understand their true costs, price products profitably, and make better production decisions. It is production software developed around real workflows and improved through user feedback.
The origin
Built From a Problem I Had Myself
Maker Forge grew out of a problem I encountered running my own ecommerce manufacturing business: understanding what a product truly costs to make and what I'm actually earning after materials, production time, labor, and marketplace fees.
Like many small product businesses, I had developed informal ways of answering those questions. As material costs changed and marketplace fees became more complicated, those approaches became harder to maintain. I wanted a better way to model the economics of the products I was actually making and selling.
As a software engineer, I built the tool I wanted for my own business.
Problem
Product costs are spread across more places than most tools recognize.
Materials are only one part of a product’s real cost. Labor, components, marketplace fees, sales channels, and business goals all affect whether a price is sustainable. Maker Forge brings those inputs together into a practical model that supports better decisions.
Role
End-to-end product ownership.
I identified the problem, designed the product model and experience, selected the architecture, implemented the application, set up authentication and payments, established deployment and CI/CD, and continue to operate and improve the product.
Approach
A connected domain model, built incrementally.
The application models stores, products, materials, components, labor and time, sales channels, channel fees, store goals, and product groupings. Those concepts feed pricing and profitability calculations, dashboards, and the Price Advisor. Supporting workflows include product duplication, subscription handling, and customer authentication.
Product lifecycle
From an operating problem to a product in users' hands.
- 01Experienced the Problem
Operating a real product business exposed the pricing and profitability problem firsthand.
- 02Defined the Domain
Materials, components, labor, production costs, fees, channels, pricing, and profitability needed a useful shared model.
- 03Built the Product
Designed and implemented Maker Forge as production SaaS software.
- 04Launched It
Deployed the application so other makers could use it in their own businesses.
- 05Worked With Users
Listened to how real makers approached their products, pricing, and workflows.
- 06Iterated
Added and changed capabilities in response to real customer needs.
Problem discovery → product thinking → software architecture → implementation → deployment → customer feedback → iteration
Customer-driven development
Building With Customers
Once Maker Forge was in users' hands, development became increasingly informed by the way real makers worked. User feedback has directly influenced product decisions and resulted in new capabilities.
- Default product pricing
- Product duplication
- Product groupings
- Pricing workflow improvements
This feedback loop is valuable because it exposes the difference between a technically complete feature and a workflow that is genuinely useful. It does not depend on claiming scale; it depends on listening carefully and improving the product.
Technology
Outcome
A working product with real operational responsibilities.
Maker Forge is deployed software with authentication, subscriptions, data models, product workflows, financial calculations, dashboards, automated delivery, and an active iteration cycle. Building and operating it has required engineering judgment across the whole system—not just feature implementation.
Professional relevance
What Building a Product Changes
Building and operating my own products changes the way I approach engineering. Architecture matters, but so do onboarding, deployment, pricing, support, usability, customer feedback, and deciding which problems are actually worth solving.
Owning the entire lifecycle creates a useful discipline: software isn't finished when the code works. It's successful when it solves the user's problem.