Co-Builder Outreach

Actual needs two kinds of partners: industry partners who want to apply it to their business or industry, and engineers who will build it. This doc covers the engineers, who build for a stake with terms worked out together.

See the role docs for detail:

Start with the first two. Together they own the core technical risk.

The Pitch, in Three Sentences

Actual is a single wearable badge that records a field worker’s whole shift (route, job sites, walking path on each property, and type of labor) with no GPS, no cellular, and no tags on equipment. Every shift starts and ends at a known shop, which closes the loop for inertial navigation; the cloud reconstructs the day with road and elevation map matching. It’s a concept with a full architecture and a founder who knows the industry, looking for engineers who want to own a piece of it.

Where to Look

Skill Where
Embedded / wearables / TinyML Edge Impulse forum, TinyML Foundation, Zephyr Discord, Nordic DevZone, Hackster.io authors
Inertial navigation / map matching ROS Discourse, IPIN conference authors, GitHub authors of inertial-odometry and map-matching projects, Georgia Tech IRIM
Cloud / geospatial backend PyATL, PostGIS community, Atlanta Azure user groups
Local Atlanta Embedded meetup, Georgia Tech alumni, ATDC, Atlanta Makers

First Message (Engineer)

Hi [Name] — I came across your [project / post] on [where]. I’m building Actual, a wearable that reconstructs a field crew’s day (route, job sites, labor type) from IMU and barometer data alone, anchored by the fact that every shift starts and ends at the shop. No GPS, no cellular.

It’s at the concept stage with a written architecture and a lot of open questions in exactly your area. I’m looking for co-builders who’d share in what we build. Would you be up for a 30-minute call to poke holes in it?

Greg Ehrenberg greg@limosa.work · limosa.work

First Call (Engineer)

Goal: find out whether they think it’s feasible, and whether they want in.

  1. Explain the problem, not the solution. Share the architecture docs beforehand if they want them (after an NDA if they’ll see anything proprietary).
  2. Ask them to attack it. “Where does this break?” A good co-builder is skeptical and specific.
  3. Ask what they’d need to prove it. Data, hardware, time.
  4. Talk terms only at the end, and only in outline: stake, milestones, IP assignment, confidentiality. Details come later, in writing.

Screening Signals

Good: asks about sample rates, mounting, drift, ground truth, and what “good enough” means to an owner. Wants data before promising accuracy. Has shipped something.

Bad: promises accuracy without data. Wants to redesign everything around their favorite tool. Can’t scope a first milestone.

Terms (outline)

  • A meaningful stake in what we build, with terms worked out together and written down
  • IP assignment to Actual (Georgia LLC) and a confidentiality agreement before proprietary details are shared
  • Work staged in milestones so either side can reassess
  • A paid contract is possible for well-defined pieces