We take ideas from rough brief to working product.
That might be a website, an application or an AI-powered tool. We help work out what it should do, design how it should feel and build the technology behind it.
Keep scrollingA few things we’ve built / 2026
That’s okay.
We can start with the problem, work out what the product needs to do and build the first useful version from there.
There isn’t one formula behind these projects. We start with what people are trying to do, then choose the design and technology that make sense for that job.
Oralyvo transcribes live speech, separates speakers and keeps the conversation in one place for translation, summaries, questions and follow-up notes.
The Foundation gets a welcoming English-and-French website for the public, plus practical tools for content, volunteers and enquiries behind the scenes.
SpendWise reads the purchase alerts and statements people already have and turns them into a private, read-only view of spending, budgets and trends.
A few things we’ve built
Each project came with a different problem, audience and set of constraints. The common thread is that the finished product should feel simpler than the work required to build it.
You do not need to decide whether the problem is “design”, “frontend”, “AI” or “infrastructure” before talking to us. Start with what you need the product to do, and we can work out which parts matter.
Websites that make it easy to understand what you do, trust the organization behind it and take the next step.
See it in Community Pulse Foundation
The kind of browser-based products people sign into and use: SaaS, portals, dashboards and internal tools.
See it in Oralyvo
Mobile apps built around how people actually use a phone: quickly, one-handed and often while doing something else.
See it in SpendWise
AI features with a clear job to do — from speech and translation to document workflows, summaries and useful automation.
See it in Oralyvo
Working out how the product should behave before development turns every change into an expensive one.
See it in SpendWise
The parts users rarely see but notice immediately when they stop working: APIs, data, accounts and integrations.
See it in Community Pulse Foundation
Process
Good products take more than good code.
We work through the problem, design the experience, build it, test it and keep improving it once people start using it.
We get clear on what you want to build, who needs it and what a successful first version should actually do.
We work out the flow, the language and the visual direction before development gets expensive.
We turn the agreed direction into a working product, connecting the interface, data and integrations as one system.
Before it goes live, we test the important journeys, fix rough edges and make sure the product is ready for everyday use.
Once people are using it, we can learn from what happens in practice and decide what is worth improving next.
What matters after the demo
A product has to hold up once real people start using it.
That means thinking about private data, slow connections, different devices, different languages and the many ordinary ways software can fail. Those details are part of the work, not extras.
Founder, WianTribe Inc.Who you’ll be working with
Founder & Product Builder at WianTribe Inc.
Fredericton, New Brunswick, Canada
My role crosses product thinking, design, engineering and applied AI. I stay close to the work from the early conversations through build and launch, so decisions do not get lost as the project moves from one stage to the next.
Sensitive provider credentials stay on the server, public forms can be protected at the edge and users only get the access they actually need.
Examples in Oralyvo + Community Pulse
Semantic structure, keyboard use, reduced-motion support and automated accessibility checks are worked into development instead of saved for the end.
Included in the WianTribe QA workflow
Connections drop, emails fail, phones interrupt people and input is not always neat. We decide what the product should do in those moments instead of pretending they will not happen.
Recovery patterns across the portfolio
The case studies are based on products we can point to and implementation details we can explain. We do not need invented metrics, client logos or testimonials to make the portfolio sound bigger than it is.
Case studies backed by the actual work
It does not need to be a polished brief. Send the rough idea, the product that needs fixing or the problem you have not found a good solution for yet. We can work from there.