Contact
If you have a gnarly interface, a brittle internal tool, or a first version that has to ship without drama, you are in the right place. Describe what “working” looks like in plain language—Infomerx reads every note and replies with specifics, not a form letter.
Currently accepting new engagements; replies usually within two business days.
Two ways to start
Send a written brief. Describe the system, what is broken or missing, and what would count as a successful first milestone.
Same inbox; subject line prefilled for triage.
Or book a 15-minute intro call if you'd rather feel out fit by voice first.
Schedule a call →Replies include clarifying questions, a rough sense of fit, and a proposed first milestone. Stack, deadlines, and constraints up front make that first email genuinely useful.
Common starting shapes
Examples of how a first milestone is often bounded. Detail and deliverables stay on Capabilities.
Vertical slice spike
Two to three weeks: discovery plus a narrow vertical slice and a clear go/no-go for the full build.
Map–list coherence slice
Two weeks: synced filters, one representative layer stack, and a short operator checklist for data prep and deployment.
Model-backed operator flow
One to two weeks: one model-backed flow with failure semantics, logging, and human-in-the-loop guardrails.
Good-fit projects
- Building or modernizing a SvelteKit (or TypeScript-first) production web application.
- Turning dense datasets into usable dashboards, maps, or operator-facing tools.
- Rescuing or refactoring fragile internal tools without betting everything on a single big-bang rewrite.
- Prototyping technical products that lean on 3D in the browser, ML or Python-backed services, or otherwise demanding browser UX.
Typical first conversation
Expect a focused working session, not a pitch. A first call usually covers what the system must do for users today, what is broken or missing, hosting and compliance boundaries, and what a credible first milestone looks like—often discovery plus a narrow vertical slice or time-boxed spike. You should leave with a clear sense of fit, rough sequencing, and whether a scoped follow-up (paid discovery or implementation proposal) is warranted.
Also helpful in the same note
- Links, screenshots, or a short Loom if they clarify the problem faster than prose.
- Whether you are after discovery, implementation, rescue of an existing codebase, or a bounded technical review.
- Budget band or procurement reality if it already constrains how work can be structured.