Building Waxlight from zero
Waxlight started as an independent product design project. I wanted to find out whether portfolio tracking, trading and automation could feel like one product instead of a bundle of disconnected tools.
I owned the work from the first problem statement to the tested prototype. That included market research, interviews, product scope, information architecture, interaction design, the visual system and prototype testing. The first cycle took eight weeks.
I worked as both product designer and product owner. The project produced a competitor map, interview synthesis, product principles, a cut first release, flow architecture, interaction prototypes and usability findings.
Because the project was independent, there was no delivery team. I prepared the flows and decision records so engineering, data, compliance and operations could review the unresolved risks before implementation.
The result was not a launched exchange. It was a validated product direction with a working model for Vault, Swap, trading bots and a professional terminal. Since the product had not launched, I measured comprehension and task completion rather than revenue or retention.
Where the project started
The first idea was broad. Put every useful trading tool in one place. It sounded convenient and produced an impressive feature map, but it did not explain why another platform should exist.
I stepped back and looked at the work people already did across exchanges, wallets, portfolio trackers and bot platforms. Twelve competing products were mapped by their main job, account model, navigation and path from monitoring to action.
I then spoke with eight retail traders. Four traded several times a week. Two used automated strategies. Two were newer investors who mostly bought and held assets. Each participant used at least three products to understand and manage the same portfolio.
A short screening survey added a wider signal before the interviews. Thirty four people described how they tracked assets and prepared a trade. Twenty seven used three or more products, twenty one reconciled balances manually and eighteen had postponed a trade because the available amount was unclear.
The recurring problem was not a missing feature. People could place a trade, run a bot or store an asset. The difficult part was keeping a reliable picture of the whole portfolio while moving between those actions.
What the research changed
My first assumption was that convenience would be the main value. The interviews changed that. Speed mattered, but control mattered more.
Core findingPeople did not need another place to trade. They needed one place they could trust before trading.
Participants checked balances in several places before making a meaningful trade. They did this because products calculated value differently and because funds could be locked in an order, a strategy or an external wallet. A single large balance was not enough to create trust.
Automation created a second gap. People remembered why they had launched a strategy but struggled to see what it was doing now. The status existed, yet the original intent, available funds and current exposure were separated across screens.
This led to a clearer product question. Could one account state follow a person from portfolio review to execution and remain understandable at every step.
The product and business bet
The primary audience was a self directed retail trader who already used several services and traded often enough to feel the cost of fragmented account information. Newer investors remained important, but designing the first release around every level of experience would have weakened the core use case.
Vault was the acquisition and activation surface because it could show value as soon as an account was connected. Swap was the first transaction and the clearest path to execution revenue. Bots were the retention layer because a running strategy gives people a reason to return, monitor and adjust it.
This sequence shaped the product plan. First prove that people trust the combined account state. Then help them complete one transparent transaction. Only after that ask them to automate a position and build a longer relationship with the product.
Business model and launch economics
I modeled Waxlight as three linked revenue layers. The numbers below are planning assumptions for testing the shape of the business. They are not operating results or an investment forecast.
Revenue grows with completed transactions.
Recurring revenue follows an active strategy.
Advanced tools fund greater product depth.
What must be true
- 01Activation reaches 15 percent
Connected accounts complete at least one swap each month.
- 02Active accounts make six swaps
Average monthly notional reaches $3,600 per transacting account.
- 03Six percent pay for automation
A running strategy creates enough recurring value for the bot plan.
- 04Two percent adopt Pro
Experienced traders pay for the denser workspace and controls.
A planning scenario
The pilot does not pay for the company. Swap revenue contributes only $6.5k at ten thousand connected accounts. Paid automation and the professional plan carry most of the early economics. At the same conversion and usage rates, the model approaches break even around twenty five thousand connected accounts.
Budget to reach a regulated beta
The range excludes regulatory capital, exchange licensing, custody deposits and liquidity commitments. Those costs depend on jurisdiction and operating model.
SWOT check
One account state connects portfolio, execution and automation. The value is visible before the first paid action.
The prototype cannot prove custody, security or live reconciliation. Trust depends on data the product does not own.
Traders already assemble this workflow across several services. Bots can turn a fragmented task into recurring use.
Regulation, liquidity and incumbent exchanges can raise costs faster than the connected account base grows.
The financial model changed the roadmap. Vault and Swap still prove trust and activation, but automation must test willingness to pay in the first beta. The professional terminal should follow only after the core account loop retains users.
Defining success before drawing screens
I set four checks for the first prototype. People needed to find their total balance and available funds without help. They needed to complete a swap and understand the amount they would receive. They needed to configure a grid bot and explain its trading range. They also needed to know whether they were using demo funds or real funds before confirming an action.
These checks kept the project focused on comprehension and control. Visual quality mattered, but it could not compensate for a person misunderstanding their money or the state of an automated strategy.
Choosing the first product loop
The initial map contained a portfolio, wallet, swap, spot trading, futures, several bot types, earning products and event markets. Building all of it at the same depth would have produced many screens and very little proof.
I reduced the first loop to three connected jobs. See the portfolio, exchange an asset and automate a position with a grid bot. Vault became the home for the account. Swap tested a short transaction. The grid bot tested a longer and riskier decision.
The professional terminal was designed after this loop was stable. Its job was to test whether the same product model could support an experienced trader without pushing terminal density into every screen. Event Markets remained an exploration rather than part of the core release.
Constraints that shaped the work
Financial software can look complete long before it is safe to use. I treated custody, compliance, live pricing and transaction recovery as product boundaries rather than details to solve after the interface.
The prototype could test whether people understood balances, fees, strategy settings and account mode. It could not prove security or behavior under real financial pressure. A production release would need a defined custody model, jurisdiction rules, reliable price sources, clear failure states and a recovery path for every transaction.
This changed what I prioritized. Demo and Real mode remained visible at the account level. Fees and minimum received stayed inside the decision flow. Complex products were kept outside the first release when their risk model did not strengthen the portfolio loop.
The first concept did not work
My first prototype opened with a dashboard of product cards. Each card led to a separate tool and each tool had its own navigation. It looked organized, but people treated the dashboard like a catalogue. They chose features by name and lost the context of the portfolio as soon as they entered one.
Only three of eight participants selected the expected starting point for a basic portfolio task. Several opened the terminal because it looked like the most capable option, then had to return when the interface exposed more information than they needed.
I removed the product catalogue from the center of the experience. The account became the center instead. Every tool would read from the same balance, market context and mode. This was the decision that turned Waxlight from a set of concepts into a product system.
The account became the product spine. Tools could change shape, but balance, mode and market context could not disappear.
A shared shell with different levels of depth
The second concept introduced a persistent account bar. It keeps the total balance, relevant market prices, connection state and the Demo or Real mode visible across the product.
Below that shared layer, each workspace is allowed to behave differently. Vault is designed for orientation. Swap is a focused transaction. Bots combine a chart with strategy controls. The professional terminal uses a dense modular layout for instruments, market data, order entry and the order book.
I considered using one universal trading form for swaps, orders and bots. That approach failed quickly. The form became full of conditional fields and people had to understand the product model before they could act. I replaced it with task specific workspaces that share data and interaction rules but not the same form.
Making the portfolio useful
Vault is the front door after connection. It answers three questions in order. How much do I have, what changed and what can I do now.
Total balance and available funds are separated because money committed to a strategy should not appear ready to spend. Recent transactions explain movement in the account. The watchlist and market movers provide context without turning the page into a trading terminal.
Deposit, withdraw and buy actions stay close to the balance. Deeper market analysis lives elsewhere. This boundary kept the home view useful for both active traders and people who only wanted to check the portfolio.
Showing the real cost of a swap
The first swap design showed only the amount paid and the amount received. It was fast, but the review sessions exposed a trust problem. People wanted to know whether the rate was competitive and what could change before execution.
I added a quote panel with the market rate, the Waxlight rate, the difference, route, fee, minimum received, price impact and slippage. These details stay visible while the amount changes.
The primary action says Review swap rather than Swap. The next state confirms the final values before submission. This adds one deliberate pause at the point where speed can create an expensive mistake.
Turning a bot into an inspectable decision
The grid bot was the hardest flow because the setup had to connect a market view, a price range, order size, profit settings and risk controls.
Early forms asked for these values in a vertical sequence. Test participants filled them in but could not explain the strategy they had created. The values were technically complete and mentally disconnected.
I moved the high and low bounds onto the chart and kept the current price between them. The form and chart update each other. Short, medium and long presets provide a starting point, while risk controls and advanced settings remain available without dominating the first setup.
Backtest sits beside Create grid because simulation is part of the decision, not a separate expert feature. Notifications and webhooks live below the setup so monitoring is considered before the bot starts.
Keeping expert tools genuinely expert
The professional terminal was not simplified into a larger version of Swap. Experienced traders need simultaneous access to instruments, the chart, order entry and market depth.
I used a modular layout so each panel has a clear job and can expand without changing the underlying account model. The same balance and Demo or Real state remain visible, but the workspace gives priority to comparison and execution speed.
This distinction became important. Progressive disclosure does not mean hiding useful data from experts. It means choosing the right starting depth for each job.
Testing the product model
I tested the revised clickable prototype with six participants. Four matched the active trader profile and two matched the newer investor profile. Each session used the same portfolio and the same four tasks.
All six found the total balance and available funds without prompting. Five completed the swap in under ninety seconds and correctly explained the minimum received. Four configured a grid bot without help on the first attempt.
The weakest result was the Demo or Real control. Only two participants noticed the mode before the first trading task. I moved it into the persistent account bar, added a text label beside the switch and repeated the mode in the confirmation state. Five of six noticed it in the second round.
Found total balance and available funds without help.
Completed the task in under ninety seconds.
Created a valid grid without assistance.
Recognized Demo or Real before confirmation.
A shared account state reduces the need to cross check balances in other products.
A transparent quote makes a swap feel safer without slowing task completion.
Presets help people start a grid bot, but the price range still needs to live on the chart.
Color alone did not make Demo or Real visible enough. The mode needed a persistent text label.
What I would measure after launch
The first activation event would be a connected account followed by one successful action in the same session. The main product measure would be the share of connected accounts that complete a swap or start a bot. Return rates after seven and thirty days would show whether the shared account state creates an ongoing habit rather than a one time portfolio check.
Those numbers would need guardrails. I would track abandoned confirmations, failed transactions, incorrect account mode, bot setups stopped before activation and support contacts after a financial action. Growth would not count as progress if people completed more actions while understanding less about their money.
What the project produced
The eight week cycle produced a tested account model, a shared product shell and five designed workspaces. Vault, Swap and Bots form the validated core. The professional terminal proves that the system can support greater depth. Event Markets remains outside the first release because it introduces a different decision model and did not strengthen the core portfolio loop.
The strongest result was not the number of screens. It was a product rule that survived every flow. The account state stays consistent while the interface changes depth around the task.
Waxlight still needs live market data, compliance work, security review and testing under real financial risk before it can become a production product. The prototype answered the earlier question and exposed the work that should come next.
What I learned
A platform is not created by putting many tools in one navigation. It becomes a platform when those tools share state and people can move between them without reconstructing context.
Trust comes from explaining the current state and the consequence of the next action. A polished balance card cannot replace available funds, execution details or a clear account mode.
The failed universal form was useful. Reuse belongs in data, behavior and interaction rules. Forcing different jobs into the same screen only makes the system look consistent.
If I continued the project, I would focus the next cycle on account connection, portfolio reconciliation and recovery from failed transactions. Those moments will determine whether the product feels reliable when the prototype becomes real.