Work shaped around the business.
These are notes on what each business needed, how the system was shaped, the decisions made along the way, and what exists today.
I usually work in one of two ways: through a fee-based engagement, or through a partnership built around a stake or revenue share. Both are normal ways I work. The right model depends on the work, the relationship, and how closely our interests should be aligned.
One project below was my own venture. It did not make it, and it stays on the record.
Tixlah
An e-ticketing platform built mainly for running and sports events.
Running and sports events need a clear flow from registration and payment through to participant management and event-day entry.
Organisers often rely on separate forms, payment tools, spreadsheets, and check-in lists. Each tool may work on its own, but together they create duplicated work, fragmented records, and more operational effort.
An e-ticketing platform built with EC Pixels Asia, bringing event listings, registration, payment, participant management, ticket confirmation, and QR-based event-day entry into one system.
Built around running and sports events.
The platform was designed around the needs of running and sports events, rather than as a general-purpose ticketing website.
Built for registration peaks and event-day operations.
The technical foundation had to support concentrated registration traffic, reliable ticket allocation, payment processing, and the operational workflows organisers need before and during an event.
I lead the platform architecture and technical direction, working closely with EC Pixels Asia on the product and event requirements. The Tiny Edges team is involved in the implementation, turning the agreed direction into the working platform.
This is a longer-term partnership with a share in the outcome.
Live with running events, with the platform continuing to evolve through real organiser and participant use.
Beyond Insights
Student-facing web and mobile products for an investment and trading educator.
Beyond Insights teaches thousands of students and already had a web student portal supporting their learning experience.
Their team brought Tiny Edges in to build their first mobile apps for iOS and Android. We are now also working on the next version of the web student portal.
The business and product direction are led by their team. They needed a build partner to turn those decisions into working software and advise on technical choices that affected delivery, maintainability, and future development.
Student-facing products across mobile and web: the first iOS and Android apps already shipped, with the next version of the web student portal now in build.
Use React Native for the first mobile apps.
I recommended React Native so that the first iOS and Android apps could be developed through a shared codebase. This reduced duplicated implementation while still allowing platform-specific work where needed.
Use Next.js for the new student portal.
I recommended Next.js because it is widely adopted, actively maintained, and supported by a mature ecosystem. That made it a practical foundation for a portal that would need to be maintained and extended over time.
Build partner on a fee-based engagement. Their team leads the business and product decisions. I advise on the technical approach and architecture, and work alongside their internal team on delivery. The Tiny Edges team handles implementation across the first mobile apps and the new web student portal.
First iOS and Android apps shipped. New web student portal in build.
Concrix
A marketplace for surplus construction materials.
Surplus construction materials hold real value, but much of the trade still happens through WhatsApp groups, Facebook posts, and personal networks. Supply and demand are scattered, making it difficult for sellers and buyers to find each other at the right time.
The first version of Concrix was built on WooCommerce so we could test the idea quickly and learn from real use. It helped validate that the problem was worth pursuing, but we are still testing the business model, understanding buyer and seller behaviour, and working towards market fit.
A custom marketplace built around listing, discovery, matching, and the workflows that emerge as we continue validating the business.
The aim is to move the trade from scattered informal demand towards a working product.
Use the first version to learn quickly.
The first version ran on WooCommerce so we could put the idea into the market without betting on a large custom build. It gave us something real to learn from and helped confirm that the problem was worth pursuing.
Move to a custom platform to follow the business, not the store.
WooCommerce helped us test the first version quickly, but it also placed the product inside a conventional e-commerce structure. We are still testing the business model and working towards market fit. A custom build gives us more room to change the workflows, pivot the product, and shape the system around what the market teaches us.
I have been the technical partner from the start, with a stake in the venture.
Because this is a partnership rather than a fee-based engagement, my role extends beyond the code into product direction, technical decisions, business-model validation, and the path towards market fit.
I am now leading the custom platform build so we have more room to pivot and learn as the business evolves.
In build. Moving from the first WooCommerce version into a custom platform, still testing the business model and working towards market fit.
Oryza Technologies: the venture that changed how I build.
Before Tiny Edges, I started Oryza. It did not become a business. I keep it on the record because leaving out the work that failed would make the rest less honest.
That a well-architected product would find its market. I built for the system I wanted to exist, not the customer who would pay for it.
My first attempt at a product company. The product worked, but the market had not asked for it.
A business around the build. Paying customers, timing, and distribution never lined up to carry it.
Start with the smallest version that could test the business model, not the architecture. Talk to the market before the code. Treat distribution as part of the build, not something that comes after.
Architecture is not enough. Business model, timing, market, and distribution decide whether a product survives. Every engagement above starts from that lesson: understand where the business is trying to go before deciding what to build. It is also why Concrix started with a lean first version instead of a custom build.
Building something that doesn't fit neatly into a standard brief?
Tell me where the business is trying to go, what is getting in the way, and what you have already tried.