A freelancer can finish a website and still have another job waiting: getting paid for it. The designer becomes the billing department. The client becomes a person to remind. Somewhere between a completed assignment and a cleared payment, a small business discovers how much administration it has quietly agreed to do.
Sail built its proposition around that interval. Launched in 2017 by the people behind Compass, it offered freelancers a way to send invoices, receive online payments, and retain payment methods for future billing. Its stated ambition was agency-style support for independent workers, with room for a personal relationship with each client.
- The product: invoices, online payments, and saved client payment methods.
- The opening: freelancers doing professional work with improvised billing routines.
- The lesson: a useful feature and a sustainable company are separate achievements.
A marketplace discovers the paperwork
Before Sail, there was Compass, a business connecting small companies with freelance web designers. The team saw the mechanics of independent work close up. Matching a designer to a client was one task; moving the assignment through to payment was another. In July 2017, Compass became a web-development agency and introduced Sail.
The launch was deliberately unfinished. Five people were working at the company. Sail was in private beta, and its makers were weighing a subscription against transaction fees. “With the beta we’re not yet charging,” Mike Wilner said. A public Trello roadmap gave users a place in the product conversation. Trying the software and choosing how to charge for it were happening together.
The money behind the earlier business needs its own label. Compass had raised $300,000 through a convertible note in 2016, from friends, family, and angels including Matt Newton. That round supported marketing and a four-person team. It belongs to the predecessor’s history, rather than a tidy funding announcement for a newly independent Sail.
The invoice is only the beginning
Sail’s useful distinction lay in connecting billing steps. An invoice records a request. Online payment provides a route to completing it. A payment method kept on file can remove the need to collect the same details at the next bill. The company’s product description joined those functions around the freelancer-client relationship.
That made the intended customer easy to picture: someone selling skilled services who also handled the office work. Design, development, consulting, and similar work involve an ongoing relationship. Each new payment can introduce another administrative interruption. Sail’s positioning treated that interruption as a product problem worth addressing.
Early reactions also exposed the competitive squeeze. In the launch coverage, freelance publicist Andrea Carter recognized an alternative to email invoices and checks. Jess Ryan compared Sail with Wave Accounting and wanted broader administrative features. One prospective user saw a simpler way to receive money; another saw an incomplete business toolkit. Those are different buying tests.
Make the next payment less work.
The loan hiding in the project
Matt Fulton, Sail’s technical cofounder, made the underlying economics unusually plain in his December 2017 argument against net-30 terms. A professional who delivers work and waits a month for payment is extending credit. The service has been consumed; the cash has not arrived. Unlike a box of unsold goods, a customized design assignment is difficult to recover and sell again.
“You are not a bank, do not work on credit.”
Matt Fulton / December 2017
Delayed payment also delays information. A misunderstanding about scope or a client’s money problems can remain hidden while the freelancer continues working. Fulton’s argument connected billing frequency with earlier discovery: a problem encountered sooner leaves less additional work exposed. The payment cycle becomes a way to check the health of the engagement.
His earlier guide to payment terms described a practical routine: agree the terms before starting, collect a deposit, obtain authorization for charges, communicate upcoming payments, and send receipts. The software could support that routine. Agreement and communication still had to come from the people using it.
Four jobs, one overloaded startup
The founders’ later reflections complicate any easy origin story. In February 2018, Wilner broke Compass into four competencies: matching designers, gathering project materials, handling feedback, and checking quality. The team had tried improving them together. Looking back, he wished they had concentrated on a smaller problem.
His revealing example was visual website feedback. Compass had built an internal feature for it; another company, Pastel, pursued that job as a standalone product. Wilner saw an opportunity the team had understood but never given enough attention. Recognizing a problem was only the beginning of choosing what to build.
In another retrospective, he described a business with little recurring revenue that needed fresh customers to keep moving forward. Earlier sales had demonstrated willingness to buy a service. They had not established a dependable growth engine. That distinction gives Sail’s billing experiment its tension: the team understood its customers’ cash-flow frustrations while confronting questions about its own business model.
Consider the difference between two promises. One says a tool will run your business. The other says it will make the next client payment easier. The second gives a prospective user something concrete to inspect: what must I do today, and what will I have to do again next week? It also gives the maker a clearer test of whether the product removes work.
A smaller promise, made concrete
For a freelancer, the portable idea is to make payment a planned part of the engagement. For a founder, it is to examine the chores inside an existing service and choose one carefully. Both lessons favor a specific process that can be explained, repeated, and tested.
There are limits. Fulton acknowledged that large clients may require their own contractor-payment systems, preventing stored methods or direct charges. A freelancer who needs accounting, expenses, and project management may also need more than Sail’s documented feature set. Its 2017 proposition remains a useful question for any business of one: how much work should getting paid require?
There is a useful distinction here between automation and an agreed process. A button cannot settle a disagreement about what was commissioned. A stored payment method cannot determine whether a client understood the price. The more interesting ambition is to make an ordinary, understood transaction easier to repeat. That is a modest product promise, but one closely connected to the working day of the person buying it.