Aegis engineered solutions build queue open

Custom builds

How to Scope a Custom Tech Project Before Anything Gets Built

Every project starts as a written scope before paid work, not a guess. Define the job, map the constraints, build the smallest useful version first, then plan the handoff.

Learning how to scope a custom tech project before anything gets built starts with writing down the job in plain language. Most failed builds do not fail in the workshop. They fail on paper first, because nobody wrote down what the thing had to do, what it had to fit, and what success looked like. A written scope fixes that before paid work begins.

This guide is for a technical homeowner, farm or small business thinking about a custom build: a bracket that does not exist yet, a sensor setup for a barn, a small dashboard, a solar backed device. It follows the same order every Aegis project follows: listen, map, build, handoff.

Describe the job in one paragraph

Write one paragraph that states what needs to exist when the project is done. Name the object, what it connects to, and what it must do. Keep it concrete. "A mount that holds a camera on the side of a steel shed, aimed at the driveway, removable without tools" is a job. "Something for the shed" is not.

Then write down what success looks like in observable terms. A part either fits the real object or it does not. A dashboard either shows the camera feeds and device status or it does not. If you cannot describe the check, the scope is not ready.

Also write down what you already tried. Knowing that an off the shelf mount cracked in the cold or that a cloud dashboard needed internet you do not have keeps the next attempt from repeating the same mistake.

Map the space, device, power and data constraints

Mapping means measuring the real conditions the build must live with. Custom work exists precisely because off the shelf products assume average conditions, and your conditions are specific. Record them.

  • Space: measure the actual object and the actual location. Photograph both with something familiar for scale. Note clearances, mounting surfaces, exposure to rain, snow, sun and dust, and whether a person can reach the spot for maintenance.
  • Device: write down every device involved, with model details where you have them. What it connects to, what plugs or mounts it already has, and what software or radio it speaks.
  • Power: state where power comes from. A device near a building may run from a simple supply. A remote device may need solar and battery sizing around the weakest season, not the best. Any work involving mains or grid connected wiring is a job for a licensed electrician, and the scope should say so plainly.
  • Data: state how information gets in and out. Local monitoring that never leaves the property has different needs than a panel you check from town. Note what already exists: network coverage, cables, hubs, screens.

Be honest about unknowns. A scope with labelled unknowns is stronger than one that guesses. Each unknown becomes a question to answer during prototyping instead of a surprise during installation.

Define the smallest useful version

Big projects get scoped by shrinking them. Ask which slice would still be worth having on its own, and scope that first. A camera dashboard that shows two feeds and device status is a complete first version; the other six feeds can follow. A sensor node that reports temperature from one barn is a complete first version; the remaining barns can follow.

This is the build step done small on purpose: prototype the smallest useful version, confirm it works against the real constraints, then extend. It keeps each round of work bounded, with a clear deliverable and a tested handoff.

Custom builds include two physical iterations by default. Expect a first version, a round of adjustments against the real object, and a refined result. Friction fit parts work this way: measure, model, print, adjust, repeat until the part fits the actual object rather than a generic specification.

An illustrative example with round numbers

The following example is illustrative, with round numbers, to show how a scope paragraph turns into a plan. Suppose a small business wants a panel in the office that shows two yard cameras and whether the gate sensor is online.

The job paragraph might read: a wall mounted display in the office showing two named camera views plus gate sensor status, readable from about ten paces, running on the local network so it keeps working when the outside internet connection drops. Success means each view labelled, each failure visible as a named state rather than a blank tile, and a handoff with notes describing how to restart each piece.

The constraint map might list: the wall space, the camera models and their stream types, the office network point the panel will use, and an electrician for the mains powered display mount. The smallest useful version is one camera and the sensor status on a spare screen before anything is purchased.

Plan the handoff from the start

A finished build is not finished until someone else can live with it. The scope should state what changes hands: the thing itself, the files behind it such as models or configuration notes, plain language notes on how it works, and a support path for what happens when something breaks or needs adjusting.

Also decide who maintains it. A monitoring panel nobody checks becomes clutter. Name the person and the routine, even if the routine is only a seasonal look at seals, cables, power and software.

Finally, keep the scope bounded. Practical custom technology means a clear deliverable and a tested handoff, not open ended promises. It covers custom parts and enclosures, device level solar and battery setups, Meshtastic nodes and local sensors with weather ready enclosures, camera dashboards and small bounded automations, and maker style builds that combine hardware, software, power, fabrication and installation planning into one finished thing.

What to send to start

Aegis Engineered Solutions starts every project as a written scope, with local setup in Durham Region and the Kawarthas. Aegis does not provide licensed engineering sign off, electrical certification, structural certification, life safety systems, medical devices, weapons or mass production, and licensed electrical work is done by a licensed electrician.

To start, send photos of the space and the devices involved, measurements of the real object and location, device details, what you have tried, what it connects to and what success looks like. Start with a brief overview of the problem; photos and technical details can follow after first contact. Reach out by email or call (705) 341-3980.

← all notes