We are a self-funded, calm company

Born as a side project, Streamline cultivate a spirit of entrepreneurship, obsessive perfectionism and passionate craftmanship, while having a relaxed work ambiance.

100% remote

We all work remotely, across all the continents and time zones: Spain, USA, Brazil, Thailand, Indonesia, Philippines, Colombia, etc.

That's why we work asynchronously with a flexible and relaxed collaboration:

Flexible time. Employees can choose the hours/days they work.
We don't work overtime, we don't stress people over unrealistic deadlines. Rush can happens occasionally, but too many rushes show unrealistic goals, that should be fixed by the manager (and not by pressuring employees).
We don't work on weekends... And won't launch features on a Friday afternoon. ;-)
We trust each other. We are team players, and we place the product over our own ego.

Heigh-ho, Heigh-ho – It ain't no trick to get rich quick!

We are focused

We have a long term vision, but short term plans:

Our developer team work on two weeks sprint to build a feature.
Long term plans always fails, so we don't plan too much ahead.
We prefer asynchronous work over meetings.We use Slack, Loom screencasts, Notion docs, etc. to avoid interruption and stay focused.
We prefer action over deliberation, and try to avoid meetings and unnecessary talks.
Although we have a monthly team meeting to stay connected and discuss strategy.

We are digital artisans

We create exceptional work: we want our products to be the best in the market. We believe EVERY maker should have Streamline part of their toolbox. 🤟
We enjoy working, and creating a product that we polish and make better every day. We put a bit of ourselves in our work.
We delight our users. We try to underpromise, but over deliver.
We use our own product. We try to put ourselves in our user shoes, and always consider their benefits before ours.
We empower other makers. Like Jeff Bezos said: "we don't make money when we sell something, we make money when we help user working faster, building better products."
We have our own side projects. We don't see employees side projects as a threat for the company, but as a great way to keep their passion, creativity flowing and develop their own life path.

We are an agile team

We put the team before the individual. No place for ego or divas 👀. We enjoy working with team players.
We believe in a horizontal /flat organisation. No bosses, everyone can be a manager on a project.
Peer reviewing: every code produced is reviewed by a peer.
We keep things simple. We value people who can explain complex problems with simple words. It is a mark of intelligence and respect for others. By minimizing the cognitive load we push to others, we save their mental energy for their own tasks.

We listen. We care.

We love feedback, even the negative one! We prefer honest feedback over false positive praises.
Critics help us to progress and make a better product.
We thank customers who give feedback, because they care enough to take time to tell us what frustrate them.
We know that for one person complaining, probably ten times more are frustrated. Every feedback or critic should be heard.
We never blame the user. If a user don't understand something or make a mistake, we blame ourselves. We should make the content clearer, or the interface easier to understand.
The maker of a feature should be responsible of supporting it, by answering to customers who complains about it or need help. If you made it, you support it or you fix it.
User satisfaction = growth. We use advertising and marketing, but our best source of sales comes from the users who recommend Streamline to their friends or colleagues.

We are organised

We use Notion to keep and organize all ideas.
We use Height app to track all tasks and bugs.
We use Slack to work asynchronously.
We often record Loom screencasts, to communicate asynchronously. Each developer also record on Friday a screencast where he present to the team the work he has done, the struggles he experienced, the approach he adopted in his work.
We try to avoid the 'bus factor' (or 'single point of failure'), by having always at least two persons being able to understand, develop or fix the code for a feature.
Before a meeting, we write the questions/problems we will talk about in a Notion document.