Product
Leveraged Mining
A compliance-first client portal designed 0-to-1 as the only designer, with the admin system rebuilt behind it. Now used by 300+ portal users across 40+ enterprise partnerships.
Overview
A staff-only mining tool became the client portal the company still runs today
Leveraged Mining began with Hashwater, an internal admin tool I designed 0-to-1 as a freelance project in 2022. I returned full time in March 2024 to design a new client portal 0-to-1 and expand the admin product behind it. Both surfaces launched in early May 2025.
I was the only product designer across both versions. The core team included the founder, a product manager, two developers, and me, with input from legal and compliance teams across the company. I led customer research, product structure, UX, UI, the design system, and production support across the client and admin products.
I built the design system from zero in Figma. Across two versions, it grew to 143 reusable components shared by the client portal and admin system. I still support the live platform on an hourly basis.
The impact
The rebuild turned a staff-only mining tool into the main client portal. Clients can check mining and package data, log participation, and export records from one place. Staff review the same history from the admin side.
300+
Client portal users
Current product data, Aug 2026
40+
Enterprise partnerships
In 8 active hosting facilities
46%
Growth in client base
2024 - 2025
Problem
Clients had to rebuild months of mining activity from spreadsheets, messages, and memory
Clients were already spending time checking mining performance and payouts, reviewing incidents, considering expansion, learning about operations, and speaking with support teams. Their records sat across calendars, spreadsheets, messages, emails, and memory.
When that information became urgent, they had to reconstruct months of work. The product needed to make record-keeping quick enough for routine use and structured enough for later review.
The existing Hashwater tool created another gap. Staff could pull mining data into one internal system, but clients still depended on the team whenever they wanted a clear view of their information.
Legal and compliance also set firm boundaries. They defined the tax guidance, approved the activity material, and checked the IRS-related wording. I kept the portal focused on structured records that clients could provide to an accountant or adviser. Qualification stayed outside the product. IRS Publication 925 lists several material-participation tests, including one where a person works more than 100 hours and at least as much as any other individual involved in the activity.
Research
Users trusted records they created themselves more than hours generated in the background
I conducted roughly 40 customer conversations through structured interviews, surveys, support conversations, and formal meetings. I compared those inputs with recurring compliance questions and daily feedback from advisers, board members, management, and internal stakeholders.
Five patterns shaped the product:
Participation often happened in short sessions of about 15-45 minutes.
Logging was delayed until it felt urgent.
Users were unsure which activities they should record.
Users trusted manual records more than a system that appeared to create hours automatically.
Clients wanted their mining and package information in the same product.
The fourth finding ruled out passive tracking and automatic hour generation. The wider research changed the scope from a basic logger into the main client portal.
What we learned
The problem went beyond slow logging. Clients needed to trust the record and understand what belonged in it. That led me to keep each entry manual, shorten the form, and put mining and package data beside the participation history.
"I keep the work in different places, and by the time I need the record I have to rebuild it from memory."
Leveraged Mining Client
Business Owner
Ideation
Manual logging stayed because users trusted it and the form took less than a minute
Keeping the log manual
We rejected passive tracking and automatic hour generation. Those options reduced input work, but they created records without a clear user action and made each entry harder for admins to explain. We accepted a small amount of input in exchange for a clear record trail.
I targeted less than one minute for a normal entry. I preselected the current date, limited choices to approved categories, asked users to describe the work, and made notes optional. After submission, the entry appeared immediately and progress stayed visible in a neutral format.
Teaching users what to record
My first scope focused on logging. Research showed that speed alone would not solve the problem because clients still needed to know which activities belonged in the record.
I worked with legal and compliance in a focused content sprint. They supplied approved rules, categories, examples, and boundaries. I turned that material into guides, tutorials, and learning content that explained which activities could be relevant, how to describe work, why consistent records mattered, what context could support an entry, and when to ask an accountant or adviser.
Expanding the product after beta
The first beta focused on participation logging. Users then asked for subscription details, service packages, earnings, payouts, and mining performance in the same place.
I expanded the product into two connected areas: participation records, and mining, package, and account data. A simple tab switch connected them. This made the platform the main client portal rather than a single-purpose logger.
Designs
Clients and staff worked from the same history, with every edit and export visible
I carried the same data model across the client and admin experiences. Clients could review mining performance, payouts, package details, participation records, learning material, and support. Staff could see what a client saw, understand how a record was created, and respond from one history.
On the client home screen, I put progress, mining data, package details, and recent activity within quick reach. On the admin home screen, I placed client and package status beside mining, payouts, and participation progress. I grouped unusual patterns, edits, deletions, and export status into a review queue. Content and category controls stayed in the same workspace because admins maintained the guidance used in the logging flow.
I also translated the legal and compliance rules into five product controls. I kept edits visible in the admin history, routed unusual entries for human review, required two-step verification before sensitive data could move in or out, kept historical imports outside the active logger, and limited exports to once every two weeks. Every export also required the receiving organization, which tied each report to its stated purpose.
The responsive client portal and admin system went live in early May 2025, built by the development team from the designs. The platform replaced separate internal mining tools, support requests, customer records, and personal logging methods with one connected product.
Lessons
The logger became the main product once mining and package data moved beside the records
I stayed with Leveraged long enough to see the internal tool become the main client product. The 2022 version served staff. The 2025 version gave clients direct access to the same core data. More than 300 clients now use it.
Research made the logging choice clear. I kept logging manual, shortened the form, and kept every change visible to staff.
Beta feedback changed the scope. Clients wanted package details, payouts, mining data, and participation records together. Putting them in one portal made the product useful beyond tax-season record-keeping.
Manual input became the trust model. Clients knew where every record came from, staff could explain each change, and the same history supported both client and admin work.
