Questions people ask
What the studio does, how a project runs, and the things worth knowing before you send a first email. If your question is not here, write to [email protected] and a person will answer it.
What does Wireframe do?
Wireframe is a product design and engineering studio in Toronto, Ontario. We take physical products from an idea to something that can be manufactured repeatedly, covering industrial design, mechanical engineering, electronics and PCB design, firmware, and the software around the device. One team carries a project across all of those disciplines rather than handing it between separate vendors, because on a small device the enclosure, the circuit board, and the code are effectively one design problem. Most of our depth is in medical wearables and diagnostic instruments, though the same integration work travels to lab equipment, assistive devices, wireless audio, and connected consumer hardware.
Where is Wireframe located?
The studio is at 401 Logan Avenue in Toronto, Ontario, Canada. It is a working shop with benches and instruments rather than an office, and visits are by appointment. We work with clients across Canada and the United States, and most projects run perfectly well with the studio at one end and a client team somewhere else.
Do you design the electronics and the enclosure, or just one of them?
Both, and we think that is the point. Electrical and mechanical decisions get made in the same room on the same day, because on a device of this size they are the same decision. A millimetre found late in the enclosure is a board respin, and a sensor that needs a different position is a mechanical change and a firmware change at once. Splitting the two across separate suppliers is what makes hardware programmes slip, because the mismatches only surface when someone tries to assemble the first units.
Can you take a product from concept all the way to manufacturing?
Yes. Work runs in phases so risk is retired in order: brief and feasibility, then concept and architecture, then detailed design, then prototype and validation, then transfer to production. Transfer means the drawings, a bill of materials that survives a real quote, and the test steps a factory needs, and we stay through first articles and the questions that come back from the floor. A design is finished when someone who has never met you can build it twice and get the same product.
Do you work on medical devices?
Yes. Medical wearables and diagnostic instruments are where we have gone deepest, because the constraints there forgive the least. We design with regulated development in mind, which means traceable requirements, design history, risk registers, and per-unit acceptance criteria where the product calls for them. We are candid about the line between engineering and certification: we build the engineering evidence a submission needs and work alongside your regulatory lead or a specialist consultancy rather than replacing them.
Are you ISO 13485 certified?
We do not claim certifications we do not hold, and we do not issue regulatory approvals. What we do is design to the practices a regulated programme needs, including traceable requirements, design history files, and risk analysis, and produce the engineering evidence your regulatory lead requires for a submission. If your programme needs a certified quality system as a contractual condition, ask us directly and we will tell you plainly whether we can meet it rather than leaving it vague.
Do you do firmware and embedded software development?
Yes, and we start it while the board is still on the bench rather than after the hardware is frozen. We write embedded C on Cortex-M class parts, with layered architectures that port between microcontroller targets, interrupt-gated acquisition, double-buffered streaming, and fixed-point signal processing where there is no floating point to spare. Power is treated as a first-class design activity: single-digit microamp sleep, peripheral teardown, wake on sensor interrupt, and per-unit production tests that measure consumption instead of assuming it. Where a product warrants it we work to MISRA-C with sub-millisecond worst-case task periods.
Can you design a wearable that runs for weeks on a small battery?
That is a large part of what we do. Devices at this scale run for weeks at single-digit microamps average, and budgets like that are won in nanoamps of quiescent current and milliseconds of wake time rather than in the choice of battery. It means designing the sleep architecture, the peripheral teardown, and the wake path together with the board, and matching the antenna against a body rather than against a bench. It also means measuring per unit in production instead of trusting the estimate.
Can you run machine learning on the device itself?
Yes, inside real constraints. We have run convolutional models a few tens of kilobytes across on parts with a couple of hundred kilobytes of flash and a few tens of kilobytes of RAM, detecting an event in under a tenth of a second. The pipeline runs from capture and labelling through to a model small enough to fit, and updates go out over the air with validation and rollback rather than through a recall.
How much does product development cost?
Engagements are fee-for-service and scoped phase by phase, so the figure depends on which phases you need and how much is unknown at the start. We do not publish a rate card, because a number quoted against an undefined project is a guess dressed up as a quote. Describe the product and the phase you are in and we will come back with a real range. Two honest signals while you plan: a serious hardware programme is a capital expense rather than a small marketing spend, and the cheapest path is almost always to spend a little up front on feasibility so the expensive phases are not wasted.
How long does a hardware project take?
It depends on the phase and the unknowns, which is why we scope phase by phase rather than quoting a single duration for a whole programme. Feasibility work is short. Detailed design and validation are where the time actually goes, and how long they take is decided by how many genuine unknowns are still in the design when you enter them. The fastest projects are the ones that spent money early identifying which questions were dangerous.
Who owns the intellectual property?
You own what we design for you. The terms are set out in the agreement before work starts, and we will not begin a project where ownership is ambiguous, because that argument only gets more expensive later.
Will you sign an NDA?
Yes, and we are glad to sign one before you share anything sensitive. We also do not discuss other clients or their products, named or unnamed, which is why there is no logo wall on this site. Expect the same discretion about yours.
Can you help us move a prototype into production?
That is one of the most common ways a project starts here. A prototype that works on a bench and a product a factory can repeat are different objects, and the gap is usually tolerances, assembly order, test coverage, and a bill of materials that has never been quoted seriously. We assemble our own boards, including fine-pitch parts on thin flex, with optical inspection and purpose-built test jigs, so iterations take days rather than a month in someone else's queue. First-pass yield is treated as a design problem: we have taken a thin-flex assembly process from a yield we were not willing to live with to comfortably above ninety per cent.
What kinds of products are a good fit for Wireframe?
What decides fit is not the sector, it is whether the hard part spans disciplines. If the mechanical, electronic, and software problems are tangled up in each other, that is our kind of problem. In practice that means body-worn sensing, point-of-care diagnostics, biopotential instrumentation, laboratory automation, assistive devices, and connected hardware that has to survive real use. If a brief is mostly a website, a mobile app with no hardware, or a pure research study, we are usually not the right studio and will say so.
How do we start a project with Wireframe?
Send a note to [email protected] with what you are building, where the work stands today, and the constraint that matters most, whether that is a date, a cost target, a technical unknown, or a first batch. A short message is enough. We will tell you whether we are the right studio before we talk about scope, and we are happy to sign an NDA first. The first paid step is usually a small scoping or feasibility phase so both sides learn what the programme really involves before committing to a full build.
If you are ready to talk, email [email protected], or take a look at the studio objects on the homepage.