About
A software studio the size of one engineer.
Smith Technologies is the company behind SailTac, and the way I take on work for other people. There is no team page because there is no team — which is the point.
Why this exists
SailTac started as software for one boat and turned into a product with customers, a licensing system and a support inbox. Building it end to end meant learning the whole chain — real-time data, desktop application delivery, code signing, payments, transactional email, DNS, update infrastructure — rather than the slice of it a job title usually allows.
Smith Technologies is the parent company that SailTac now sits under, and where future products will live. It is also how that same capability gets offered to other people who need something built properly and would rather deal with one accountable person than an agency.
How I work
Scope in writing, price fixed, working software you can click through early. I would rather talk you out of a bad project than take the money — partly on principle, mostly because a studio this size lives on people recommending it.
I take on a small number of projects at a time, deliberately. If the timing doesn't work I'll say so rather than stretching myself thin across yours and someone else's.
Scott Smith
Engineer, and the whole company. I work in IT day to day and build software the rest of the time — SailTac is the product that came out of it. Before any of that, eight years as a carpenter.
Based in Metro Detroit, Michigan. Happy to work remotely.
Get in touch
scott@smithtechnologies.ioBefore software
Eight years building things you can stand on.
I was a carpenter for eight years before moving into IT — residential remodelling at one end, crews on nine-figure commercial projects at the other. It is an odd line on a software CV. It is also the most useful one.
Construction is unsentimental about finishing. A framed wall nobody can close up is worth nothing, and a kitchen that is 95% done is a kitchen a family cannot cook in. You quote the job, and if you misjudged it that is your problem rather than the customer's. You work from drawings that are wrong in some small way on nearly every project, and the job is to catch it and sort it out — not to build the mistake precisely as drawn and point at the plans afterwards.
None of that is a metaphor. It is the same work with different materials.
A fixed price means something
You walk a job, you quote it, you live with the number. Eight years of that is why every project here is scoped in writing and priced fixed rather than metered by the hour — and why the estimate gets the care it deserves instead of being a hopeful guess.
The last 10% is the part people see
Framing is forgiving; trim is not. Nobody admires your joists. They notice the gap at the casing. Software has the same shape — the polish, the error message, the empty state and the install are what the customer actually experiences.
The drawings are always a bit wrong
Every set of plans has a conflict in it somewhere, and finding it on site beats discovering it after the concrete cures. Reading a spec for what it forgot to say is a trades habit long before it is an engineering one.
Principles
What I actually believe about this work.
Finished beats clever
The interesting technical decision is usually not the one that decides whether a project succeeds. Shipping, supporting and updating it is. Most of the engineering effort in a real product goes somewhere unglamorous, and pretending otherwise is how projects end up 90% done for a year.
Say the uncomfortable thing early
If a schedule is unrealistic, a feature is a bad idea, or the thing you want already exists as a $20/month product, you should hear it in week one rather than month four. Being pleasant about a project that's heading for a wall isn't a service.
No lock-in
Code, accounts, domains and deployments go in your name from the start. A studio that makes itself hard to leave is telling you something about how it expects to keep the work.
Proven beats trendy
TypeScript, React, Next.js, Postgres — current, actively developed technology with real communities behind it. The line that matters isn't old versus new, it's proven versus unproven. I'll reach for something released last year when it's genuinely the best answer, and I won't stake your product on a framework that may be abandoned before you next need to change anything. It also means the next developer to open your codebase already knows how it works.