Jared Brown and the message worth answering

Jared Brown was accustomed to people arriving with an idea and leaving him with the work. A developer with a computer science degree from Purdue, he had heard versions of the proposition before: somebody had spotted a fortune; perhaps he would kindly build it. Then a stranger named Dave Nevogt appeared in his LinkedIn inbox. Brown agreed to a call. He expected another enthusiastic introduction to a project that existed mainly in its owner's imagination.

Nevogt had brought something more useful. There was a working prototype, a website, a way to take payments and evidence from trying to sell the thing. He needed a technical partner for software that would help him manage remote contractors. Brown still took three months to decide. For someone who would later describe himself as cautious about financial risk, that pause belongs in the story as much as the eventual yes.

The company became Hubstaff. The interesting part is how much of Brown's working life had prepared him to recognize a proposal worth answering.

Before the timer, a camera

Brown had been making software since high school. He graduated from Purdue in 2004 and built a consulting business. His career already contained a lesson in how quickly an apparently simple product could become complicated.

On a vacation during the early days of the iPhone App Store, he and his future wife began talking about camera apps. Taking a photograph required tapping a small on-screen control. She suggested using the volume button as a shutter. Their first release took a simpler approach: tap anywhere on the screen to take the picture. Other features followed.

Then an update ran into Apple's review process over unsanctioned API calls. Brown contacted TechCrunch about the rejection and attracted publicity. That brought prospective consulting clients, followed by another education: projects that left him paying subcontractors while losing money himself.

Attention could bring work through the door. Collecting enough money to pay for that work was a separate skill. It helps explain the appeal of a product with a recurring subscription and a partner who had already tested whether people wanted it.

A partnership divided down the middle

Nevogt had gone looking for a co-founder, rather than another person to manage. His proposed ownership split was equal. Each founder would have a substantial reason to keep going when the work became tedious, which software has a reliable talent for doing.

The division of responsibility was equally practical. Nevogt understood marketing and search traffic. Brown could direct the technology. Different expertise gave them room to make decisions without turning every question into a two-person committee.

Brown had also shipped Talentopoly, a community for developers and designers. To Nevogt, that mattered: here was someone who could finish and release a project. A working site supplied evidence that a list of skills could only promise. In a business whose first product had already exposed the limits of outsourced development, that distinction carried weight.

“Spec out your tasks.”

Jared Brown, on the habit behind clearer work

The money went into the software

The founders put in $26,000 apiece. Most of that initial capital paid for desktop development, an area where they needed additional expertise. Brown worked on the server-side Ruby on Rails code while two developers built the applications for Windows, Mac and Linux. Nevogt handled marketing and operations.

The first build took time. Brown dates the start of coding to May 2012, the beta to later that year, and the introduction of charges to August 2013. Between writing software and asking people to pay, there was a long stretch of making it useful. Those dates put some texture on the word startup. They describe months of work before a paid product, followed by years in which the founders had to keep earning another renewal.

That allocation tells you something about the enterprise. The money was buying a usable product across the machines customers actually owned. A time tracker that works beautifully on the founder's laptop has a rather limited addressable market.

Bootstrapping also made their choices concrete. They devoted their time to the company rather than the search for investment. Revenue from customers became the means of continuing. Every subscription linked the next round of development to a person who had found the previous round useful enough to pay for.

Instructions are part of the product

For Brown, building a team required more than recruiting able programmers. He has acknowledged that earlier ventures suffered when he handed over projects without enough written detail or follow-through. Delays and disappointing work were expensive ways to discover the missing instructions.

His response was to break ideas into components, identify the work that genuinely needed his involvement, and give other people clear ownership of the rest. Processes should be recorded and revised when someone finds a better method. That way, expertise survives a colleague's departure and the next person can improve it.

There is a developer's instinct in that approach: make the system easier to understand before asking it to do more. The specification has a social purpose, too. It saves a teammate from having to guess what the boss meant.

Brown's enthusiasm for the television series Cosmos offers a useful counterweight. After hours among tiny programming details, he enjoyed the reminder of how small those details look against an enormous universe. Even a demanding software project benefits from an occasional change of scale.

Leave a useful answer for the next time zone

Hubstaff was remote from the beginning. Brown's explanation of asynchronous work is unusually specific about its friction. If a colleague is asleep, a question may sit unanswered for hours. Send an incomplete question and the eventual response may simply ask for the information you should have supplied.

That delay gives people a reason to search for an answer themselves, or write a better question. A task needs enough context for someone to pick it up during their own working day: checklists, attachments, mockups and a clear account of what comes next.

Brown has recommended grouping meetings into the morning and leaving afternoons available for sustained work. The underlying problem is familiar to anyone who writes software. A calendar can contain several empty half-hours and still offer nowhere to think through a difficult change.

He has also described using paid test projects when hiring developers. A few hours of relevant work lets both parties experience the arrangement. The candidate gets a look at the company; the company gets evidence beyond a well-delivered interview answer.

The moving target called enough

Ask Brown about success and the finish line begins moving. In an early account of his business philosophy, he treated each achievement as a platform for the next expansion. A funding round or a revenue figure could mark progress without guaranteeing the company's future.

His choice of a personal hero was more revealing than a list of business milestones. He named Jorge Muñoz, known for providing meals to day laborers in Queens. Brown admired the habit of seeing a problem, taking initiative and showing up repeatedly. The scale of the gesture mattered less than the consistency.

That appreciation for steady work sits beside practical financial advice: invoice promptly and allow for customers paying late. A budget can look respectable while the bank account presents an opposing opinion. His experience with consulting had given that observation some bite.

In August 2023, Hubstaff accepted a growth investment from WestView Capital Partners after its long period of bootstrapping. Brown wanted support for the next phase, including expansion to larger companies. The decision changed the financing of the business while continuing the same project he had joined a decade earlier.

By December 2025, he was discussing a company of more than 130 people and roughly $33 million in annual recurring revenue. The conversation itself had begun with a chance encounter in a parking deck at XO Ruby. Brown's business life seems to leave room for an introduction in an unpromising setting.

Remote people occasionally need a table

Brown's recent reflections on a Hubstaff retreat in Barcelona add a wrinkle to his commitment to remote work. Seeing colleagues together helped correct the personalities people had assembled from Slack messages, response times and punctuation.

Someone who seemed entirely businesslike online could keep a dinner table laughing. A teammate who was difficult to read through a screen became easier to understand in person. Working remotely made the company efficient; meeting occasionally gave its people more context for one another.

He regarded the retreat as maintenance for the relationships behind the work. It is a useful distinction for a founder selling software that makes work measurable. A system can tell you when somebody logged time. Sharing a meal might tell you why you had misunderstood them.

The next question for a time tracker

In 2026, Brown's attention has turned toward helping managers interpret the information their tools already collect. His argument is that gathering operational data has become routine, while understanding what changed and deciding where to act still consume too much effort.

Hubstaff's September announcement gave that ambition a concrete form: a command-line interface, enhanced API access and an MCP server to connect workforce data with AI assistants. The intended shift is toward asking a question and receiving a useful answer without first assembling another report.

That is a new interface for an old concern in Brown's career. He has spent years trying to make the next piece of work easier to see, explain and hand over. It began with a developer listening carefully to a stranger who had done his homework. The next chapter depends on whether the software can repay that kind of attention.