People occasionally ask us about our name. “The Proper Motion Company” does not immediately suggest software development. It sounds like it might belong to a physics lab or an animation studio. The name is borrowed from astronomy, and the concept behind it is the reason we chose it.
In astronomy, proper motion is the apparent movement of a star across the sky relative to more distant background stars. It is distinct from the apparent motion caused by Earth’s rotation or orbit. Proper motion is the star’s own movement – its true, intrinsic trajectory through space. Every star has one, but because the distances involved are so vast, you can only detect it through precise, sustained observation over months or years.
That concept maps directly to how we think about building software and running a company.
Intrinsic Direction Over Apparent Movement
The technology industry generates an enormous amount of apparent motion. Frameworks rise and fall. Hype cycles inflate and deflate. Every quarter brings a new paradigm that promises to change everything: blockchain, metaverse, no-code, AI-everything. Companies that chase each new trend look busy. They are shipping blog posts about their Metaverse strategy, launching an NFT marketplace, pivoting to an AI-first approach. From a distance, it looks like motion.
But much of it is not intrinsic. It is reactive. It is a star appearing to move because the observer’s planet is spinning, not because the star itself is going anywhere.
We chose the name Proper Motion because we wanted to commit to a different kind of movement – deliberate, self-directed, and measurable only over meaningful timescales. Our direction is set by the problems we find genuinely important, the craft we want to practice, and the relationships we want to build. Not by what raised the most funding this quarter.
This is not a rejection of new technology. We adopt new tools constantly. But we adopt them because they solve a specific problem for a specific client, not because they appeared on a trend report. The distinction is between “We are using TypeScript because its type system catches bugs that cost our client money” and “We are using TypeScript because everyone is talking about it.” The outcome might be the same; the reasoning process – and the likelihood of making good decisions consistently – is not.
The Value of Sustained, Precise Observation
Detecting a star’s proper motion requires patience and precision. You cannot observe it in a single night. You need repeated measurements, taken carefully, over an extended period. Only then does the true trajectory become clear.
Software development has a similar dynamic. The most important insights about a system – what the users actually need, where the architecture is straining, which features drive retention and which are unused – only emerge over time. A two-week discovery phase gives you hypotheses. Six months of production data gives you answers.
This is why we favor long-term partnerships over one-off projects. A three-month engagement delivers a functional application. A twelve-month engagement delivers a functional application that has been observed in production, adjusted based on real user behavior, and refined based on actual performance data. The second outcome is categorically better because it incorporates information that simply did not exist during the initial build.
We have worked with clients where the feature they were most excited about during planning turned out to be the least used in production. And the throwaway utility we built in a day to solve an immediate problem became the most-used part of the application. You only learn this through sustained observation. You only act on it if your engagement is structured for iteration, not just delivery.
Small Movements, Compounded
The fastest known proper motion belongs to Barnard’s Star, which moves about 10.3 arcseconds per year. That is a tiny amount – roughly the apparent width of a dime viewed from two miles away. But over centuries, it adds up to a significant displacement. Barnard’s Star will be the closest star to our solar system in about 10,000 years, overtaking the Alpha Centauri system, purely through the accumulation of that small annual motion.
We think about our work the same way. The daily improvements are small. A slightly cleaner API boundary. A test that catches a regression before it reaches production. A deployment pipeline that is two minutes faster. A naming convention that makes the codebase more navigable. None of these are dramatic. None of them make a press release.
But compounded over years, they produce software that is qualitatively different from what is built in a rush. The codebase that receives consistent, small improvements for three years is not 156 times better than the one that received one big improvement – it is better in ways that multiplication cannot capture. It is navigable. It is trustworthy. New developers can onboard in days instead of weeks. Changes ship confidently instead of fearfully.
This philosophy extends to how we run the company itself. We are not trying to grow into a 500-person agency. We are trying to get measurably better at our craft each year, serve our clients more effectively, and build a body of work that we are proud of on a twenty-year timescale. The annual increments are small. The compounded result, we hope, will be significant.
See also: Why the Traditional Software Agency Model Is Broken
Measuring What Matters, Ignoring What Doesn’t
Proper motion is measured in arcseconds per year – an extraordinarily precise unit. Astronomers chose this unit because it captures exactly what they need to know: how fast the star is actually moving, separated from every other source of apparent motion. The measurement itself is an act of intellectual discipline, stripping away noise to find signal.
In software, the noise-to-signal ratio is terrible. Vanity metrics abound: lines of code written, story points completed, number of features shipped, GitHub commit streaks. None of these measure what matters. Lines of code are a liability, not an asset. Story points measure effort, not impact. Feature count ignores that one well-designed feature can be more valuable than twenty poorly conceived ones.
The metrics we care about are client-outcome metrics: Has the application reduced the time it takes to complete the core workflow? Has it reduced error rates? Has it increased the number of transactions the client can handle without adding staff? Is the client’s revenue growing because of capabilities the software enables?
These are harder to measure than story points. They require understanding the client’s business deeply enough to identify the right metric in the first place. But they are the only metrics that tell you whether the work actually mattered. Everything else is apparent motion.
Building in the Open, Moving at Our Own Speed
There is a particular form of pressure in the technology industry to perform productivity. To tweet about what you shipped. To publish case studies immediately. To present every project as a smashing success. The appearance of velocity becomes a product in itself.
We have deliberately chosen a different pace. We write about our work when we have something genuine to share. We publish case studies when we have enough distance to honestly assess what worked and what did not. We prefer depth over frequency, substance over cadence.
This is not because we are slow. It is because we have seen what happens when the pressure to appear productive overrides the discipline to be productive. Corners get cut. Quality gets traded for quantity. Teams optimize for the demo, not for the deployment. The software looks impressive in a screenshot and falls apart under load.
Proper motion is quiet. It does not announce itself. It is only visible to those who look carefully, over time, with the right instruments. We are comfortable with that. The work speaks for itself to the people who are paying attention – our clients, our collaborators, and the users who rely on the systems we build.
Why It Matters to You
If you are evaluating software partners, the name is a signal about what to expect from working with us. We will not rush to impress you with a flashy prototype that cannot scale. We will not chase the framework of the month. We will not pad our timelines to look busy or compress them to look fast.
What we will do is listen carefully to your problem, propose a solution grounded in our experience, build it with the kind of care that holds up over years, and stay engaged long enough to see whether it actually worked. That is our proper motion. It is steady, it is intentional, and it compounds.
The name is a daily reminder to ourselves as much as a signal to others. When the temptation arises to chase a trend, to cut a corner for short-term gain, or to measure our progress by someone else’s yardstick, the name pulls us back. What is our actual trajectory? Are we moving on our own terms? Is the direction still the right one? These are the questions that matter. The rest is noise.
If that approach resonates with how you think about building your business, we would like to hear from you.