Gary Gaspar had a website on one screen and Trello on the other. A problem appeared. He took a screenshot, opened it in Sketch, drew the necessary box and arrow, saved it, created a card and uploaded the image. Then came the page address, screen size and browser version. The next problem required the same little expedition. After an hour, he went to the coffee machine.
There he found Olivier Kaisin, a colleague with a useful qualification: he could build things. Gaspar wanted a browser extension to take the screenshot, accept an annotation and create the Trello card with the address already attached. Kaisin thought it was possible. The request had the virtue of being specific. Nobody needed to arrange a workshop to establish whether Gaspar was annoyed.
That exchange became part of the origin of Marker.io. The company’s business would grow around a task its founders knew intimately: helping one person show another person what had gone wrong on a website.
Three colleagues, then three partners
Gaspar’s route to that coffee machine included a corporate job he disliked and an early attempt to work for himself that did not go as planned. He joined WooRank, an SEO company, where he learned about digital marketing and product management. More consequentially, he met Kaisin and Emile-Victor Portenart.
Their agency came together gradually. One colleague already had a website business on the side and left to run it. Gaspar joined him, seeing a chance to learn about customers and building a business, even though services were unlikely to be his permanent destination. The third colleague began freelancing and took a place in their office. Eventually, they were working together.
The division of labor endured: technology, design and product, business. Gaspar has been cheerfully dismissive of the grand titles attached to those jobs. The arrangement gave three people different reasons to care about the same website. A client could send a muddled request and inconvenience all of them at once.

The products they did not need
An agency offered a living, but project revenue kept requiring another project. Gaspar wanted the recurring income of a subscription business. The partners tried other products before settling on Marker. Among them were software for restaurant owners and a food-sharing concept. They failed.
His explanation was blunt: the founders had been building for situations they did not understand from the inside. They were much better acquainted with the inconvenience of reporting website bugs. That gave them a useful advantage when deciding what to build and how to explain it.
He also learned to distinguish the people discussing a product from the people using it. One person offered several improvements without having used Marker. Another customer stopped receiving onboarding emails while continuing to use and pay for the software. Attention and usefulness had turned out to keep different schedules.
Eventually, leaving the agency required a transition of its own. Existing clients still needed looking after. Winding down that work took roughly six months. The decision to commit to the product was, in Gaspar’s telling, partly a leap of faith.
A launch deserves a rehearsal
Getting the product in front of strangers supplied another education. Marker’s first appearance on Product Hunt happened before Gaspar was prepared. Someone else submitted it; it attracted 20 upvotes and 60 visitors. The internet had briefly opened the door and then carried on with its day.
For a subsequent launch, the team had a redesigned experience, new onboarding, a screenshot editor and a Jira integration. There was a week spent on the tagline and, for Gaspar, two days learning to make a demonstration video. The work of explaining the tool was becoming a job in its own right.
He contacted Bram Kanstein, who was open to hearing product pitches, and made the submission easy to understand. Gaspar had also learned something about preparation: a useful product still needed a coherent introduction. A listing was a moment in which people might pay attention. It did not relieve the founder of having something clear to say.
His own launch account went into the unglamorous details. He prepared material for journalists, built a plan in Trello and mapped the video’s storyline before recording. The product helped people communicate visually; he had to do the same for the product.
Repeatedly watching the demonstration brought its own trap. He accelerated it until the team could barely follow the action. Familiarity had made the narrator impatient with the audience. Slowing the video down was a small correction with a familiar business lesson: the person seeing something for the first time needs a different pace.
Gaspar later shared the process publicly. The willingness to explain the awkward parts matters to the portrait. Here was the business co-founder showing the rehearsal, the props and the mistake in the edit.
The spreadsheet with a warning
In October 2016, another piece of founder homework became a public resource. While preparing to raise seed funding, Gaspar needed a financial model. Traditional templates fitted subscription revenue poorly; other SaaS models were more complicated than he wanted. He built a simpler spreadsheet and offered a copy to other founders.
“Your plan will turn out to be false”
Gary Gaspar, writing about early financial models, 2016
That was his starting assumption. A forecast could still demonstrate whether someone understood the business: what brought in customers, what drove revenue and what the company would need to spend. The exercise made the founder explain the mechanism behind the hopeful numbers.
It is an appealingly awkward ambition for a spreadsheet. The file cannot make the future cooperate. It can make the person filling it in confront the questions. Gaspar’s stated hope was to save other entrepreneurs time they could spend creating value for customers.
The business guy learns flexbox
The same instinct resurfaced inside Marker.io. Its marketing website had been custom built and belonged, operationally, to engineering. Marketers provided words. Designers provided assets. Developers made the changes. Every update involved a dependency.
In 2020, the team gave Webflow a serious look. Moving the site gave marketing control over its own pages and freed engineers to concentrate on the product. Gaspar took classes through Webflow University, learning concepts including flexbox until he could make entire landing pages himself.
A chief executive learning page layout is a pleasing addition to the usual picture of executive work. It also follows directly from his original complaint. If an ordinary task keeps waiting on a handoff, examine the handoff. Sometimes the answer is a new product. Sometimes it is the CEO sitting down to learn CSS layout.
Agreement inside the product team also needed work. As Marker developed, finding the right problem and settling on a solution became harder. In 2020, the company adopted Whimsical for mind maps, user flows and early wireframes.
Gaspar valued small conveniences: keyboard shortcuts, tidy alignment and a tool that colleagues without technical backgrounds could contribute to. Those preferences suit a founder whose own role sits beside engineering rather than inside it. A shared drawing gives everyone a place to point before anyone commits to building.
Another handoff emerged in sales. Product usage, support conversations and prospective deals were difficult to bring together. Marker adopted Attio to connect customer and product information. A conversation could begin with knowledge of the customer’s plan and activity, rather than a hurried reconstruction from separate systems.
Different software, familiar frustration. The business was still paying attention to the work required to get useful context from one person to another.
- 01 Spot the issue
- 02 Show the context
- 03 Give it an owner
- 04 Set the priority
A simplified view of the work Marker.io helps teams organize.
Feedback needs an owner
By April 2025, Gaspar was announcing issue assignees in Marker. Teams wanted to organize incoming feedback before sending it into another tracker. Someone needed to be responsible for the item. The update supplied that person, along with views for unresolved, assigned and unassigned work.
Priority levels followed in May. A broken checkout and a minor copy change should not have to compete as indistinguishable entries in a list. The feature let teams express urgency and notify an assignee when a problem needed immediate attention. The original screenshot shortcut now sat within a larger sequence of decisions.
The customer conversations remained visible, too. On a public feature-request thread about video reporting, Gaspar asked why customers still needed recording after session replay became available. A customer explained that people wanted to narrate an issue while showing it. The exchange catches the difference between providing technical context and letting a person explain what they mean.
Who keeps the shortcut working?
More recently, Gaspar has pushed back against the excitement around replacing paid software with hastily built internal tools. Maintenance and awkward cases remain after the first version works. His argument is that the service inside software-as-a-service carries obligations of its own.
It is a useful complication in his story. His company began with colleagues building something for themselves. He now runs the business responsible for keeping that sort of shortcut useful to other people. A working first version opens a relationship that needs tending.
Outside the product, his company biography supplies a less complicated enthusiasm: basketball. The professional record, meanwhile, keeps returning to the same modest unit of progress. One less repetitive task. One clearer explanation. One person who knows what to do next. An hour at a desk was enough to get his attention. Keeping that hour from returning became years of work.