We use Sass at Remote, especially the .scss syntax. Sass gives our team features that don’t exist yet in CSS, like nesting selectors, mixins, functions, variables (although CSS has now custom properties they have differences), which are great for productivity.

It’s a good opportunity, when starting a new project, to look for formatting, naming and architecture standards.

We’ve been using a pattern by Hugo Giraudel, the 7-1 Pattern in almost all of our previous projects and it’s being a good fit for all our needs. You can find more about it here.

Using this pattern you have all your sass partials in 7 different folders and a single file at root level that imports all folders. This is used to later compile everything to a single CSS stylesheet.

base/
components/
layout/
pages/
themes/
abstracts/
vendors/
main.scss

This has been our go-to architecture and we’re following almost all recommendations. However, there are some nuances that we felt the need to overcome and so we created our own approach to this architecture so that it could fit codebases of all sizes.

We didn’t like the idea of having a file importing every sass file on the project because we would get a big CSS file with all our code being used on every page and having a lot of unnecessary CSS being loaded.

There are only two folders that we need to import on any page, the abstracts and the base folder.

For these folders, we’ve created a _global.scss file where we’re importing all files inside.

/abstracts
  _functions.scss
  _variables.scss
  _mixins.scss
  _global.scss
/base
  _general.scss
  _fonts.scss
  _global.scss

// abstracts/_global.scss
@import 'variables';
@import 'functions';
@import 'mixins';

// base/_global.scss
@import '../abstracts/global';
@import 'general';
@import 'fonts';

Since we need the files in the abstracts folder in any scss file to be able to use the mixins, variables or functions, we can save some time and import the _global.scss in the abstracts folder in the _global.scss of the base folder. Without this, we would have to import abstracts _global on every single page.

We’re using webpack to generate multi entries and outputs to create a specific CSS file for each page and importing only what it needs. You can find more info on how to use webpack with Sass here. With this solution, we can create a sign-in.scss file in the page folder that will import all the defaults and specific components to be rendered on the page.

// sign-in.scss
// scss/ is an alias

@import 'scss/base/global';
@import 'scss/layout/header';
@import 'scss/layout/form';
@import 'scss/components/buttons';
@import 'scss/components/auth';
@import 'scss/components/loaders';

We’ve started following the folder structure that the 7-1 pattern suggests, but on all projects that we’ve worked with, none of them had the need for all the folders.

So, if you take an approach of using only what you need, independently if it’s a small or big codebase it only impacts the number of files.

/abstracts
  _functions.scss
  _global.scss
  _mixins.scss
  _variables.scss
/base
  _fonts.scss
  _general.scss
  _global.scss
  _typography.scss
/components
  _header.scss
  _form.scss
  _buttons.scss
  ...
/vendor
  _bootstrap.scss
  _normalize.scss
/pages
  auth.scss
  homepage.scss
  ...

The /abstracts folder contains all the sass helpers you can create to help you out on your project. This is all about sass tools, variables, mixins, functions, placeholders, etc.

We’re using the _global.scss to import all files so we don’t bloat other files with these imports.

The /base folder contains all the boilerplate of the project. It’s where we set the default styles, import custom fonts, set the default style for the headings, paragraphs, hyperlinks.

Following the component-based approach of Javascript frameworks like React, we treat everything a component. These are independent, reusable pieces of the UI and you can think of components like a navbar, a header or a button.

That’s why instead of using a layout folder for elements like a Footer or a Header, we create pages that are composed by components.

The /vendor folder contains all the third party files that the application needs. It can be a reset CSS file, bootstrap, anything you could think of.

If these files should be included in any page of the website, we import in /base/general.scss.

The /pages folder should contain the specific styles for each page with the filename being the name of the page. In our use case, we use webpack to create specific CSS files for each page and import all the default styles and the components that I need for each page. You can find more information on how we do this here.

This approach allows us to import only the code that the page needs and reduce the size of the file.

// billing.scss
@import 'scss/base/global';
@import 'scss/components/header';
@import 'scss/components/footer';
@import 'scss/components/form';

.billing {
  max-width: 640px;
  margin-top: pixelToRem(90px);

  &-section {
    margin-bottom: pixelToRem(60px);

    p {
      margin-top: pixelToRem(5px);
    }
  }
}

If you’re not using something like webpack to bundle and convert your javascript and sass/less files and you have a main.scss where you import everything, this approach allows you having a _global.scss file per folder importing all the other files and import these globals to your main file.

// main.scss
@import 'scss/abstracts/global';
@import 'scss/base/global';
@import 'scss/components/global';
@import 'scss/pages/global';
@import 'scss/vendor/global';

We hope you find this article helpful, as the 7-1 pattern was very useful to us. With the structural foundation for our SASS codebase and with a few tweaks here and there we got to a point where we’re finally happy with its productivity and organization.

We’d love to hear what you think about this and how we could further improve this approach!

We use Sass at Remote, especially the .scss syntax. Sass gives our team features that don't exist yet in CSS, like nesting selectors, mixins, functions, and variables (although CSS has now custom properties they have differences), which are great for productivity.

How to structure your Sass codebase

At Remote we have a 30-minute daily team call. It consists of two parts: a short agenda, and some time to bond. In the first months we’d just discuss whatever came to mind. That worked OK, but lead to certain people speaking more than others. To get to know each other a bit better, and in different ways, we introduced the question of the day.

Every day now, we end the meeting with the question of the day. Everyone answers the question, and depending on the question, hilarity, or more serious discussions come from those answers.

Anyone can submit a question, and we have had both very serious and very funny questions. We’ve compiled some of our favourite questions below.

Susana and Alex (design and product at Remote) remarked enjoying both the serious, as well as the less serious questions.

What makes you anxious and how do you deal with that?

What was the ‘butterfly effect’ moment of your life?

If you had to have another career/job what would it be?

Hardest conversation / meeting at work you’ve ever had?

How do you explain to your parents what you do for a living?

What changed the way you view the world? Event? Book? Movie? Class? Something else?

What would you do if you had enough money to retire today?

Of all your worldly possessions, what would be the hardest to give up?

You get to spend a full day with anyone you want, who is it?

What’s your best memory from high school?

What kind of animal would be your sidekick?

What are your favorite ice-breaker / getting-to-know-each-other questions? Other tricks to bond remotely?

At Remote we have a 30-minute daily team call. It consists of two parts: a short agenda, and some time to bond. In the first months we'd just discuss whatever came to mind. That worked OK, but lead to certain people speaking more than others. To get to know each other a bit better, and in different ways, we introduced the question of the day.

Bonding remotely: Question of the day

Today we’re launching Employ, our global employment, payroll, benefit, compliance and everything-you-need to employ people across the world - product. We have been working on this for almost a year, and are finally able to offer our service in the first two countries (The Netherlands and United Kingdom). With many more following shortly. You can find the full list of countries here.

Our job board is still available (and will continue to expand) at remote.com/remote-jobs.

If you want to hire someone in a different country, and you intend to treat them as any other full-time employee, you need to comply with local laws and taxes. In most countries, this means you need to establish an entity there, set up payroll, learn about local labor laws and implement them. Now that you have entities in different countries, you’ll need to think about transfer pricing, currency fluctuations and (believe us…) a lot of other complex things. This all just to hire someone in another country.

Remote solves this with Employ. Rather than going through the above, you can employ someone in another country through Remote. You sign up with us, invite your new employee, and we’ll take care of the rest. We employ them locally with a contract that is exclusive to you. From that moment forward, we invoice you monthly and we take care of payroll, taxes, benefits, and anything that comes with employing someone in that country.

Remote owns every entity, so you only deal with us directly. No third-parties. This makes us much more flexible, faster, and significantly more affordable than alternatives. On top of that, we have a very good looking app, that allows everyone to easily review, approve and edit payroll, payslips (if you’re the one getting that), and any personal information.

If you want to make use of Employ, you can now sign up here! Even if we don’t support the countries you’re interested in yet, signing up will allow us to reach out when we do (we’ll send you an email to ask which countries you’re interested in).

Remote owns entities around the world that act as employer for your employees. Upon signing up, you sign a contract with Remote that allows us to employ one or more employees for you. Employees that are employed through Remote will sign a normal employment contract with Remote that specifies their rights and duties. This is a local contract, and will give them their local rights. It also includes an intellectual property and invention agreement.

Remote charges a percentage over total cost of employment, every month. We vary this percentage by country, as some countries are much more expensive to operate in than others. We try to be as affordable as possible.

Every month you get a single invoice to pay all your employees. For each employee we charge our percentage (based on region).

There are no setup-costs, no hidden fees, no surprises. Take all the costs of employing someone, add the percentage for our costs: that’s what you pay.

We believe that remote.com should be the home for anything related to remote work. Remote jobs, resources, companies, and tools. We’re dedicating more people to expanding and improving it. Over time, we hope that Remote can help any company with scaling up, becoming distributed and more efficient.

To be able to build Remote, and Employ, we need feedback on what we can do better - or just different. Please let us know your thoughts and questions below, on Twitter or by emailing us directly. We’d love to hear your thoughts.

Today we're launching Employ, our global employment, payroll, benefit, compliance, and everything you need to employ people across the world product. We have been working on this for almost a year, and are finally able to offer our service in the first two countries (The Netherlands and United Kingdom) with many more following shortly.

Bonding remotely: Question of the day

Remote’s favorite questions

You may also like

What is global payroll?

Remote for Good recognized as a Fast Company World Changing Idea

Remote's total rewards policy

How to manage global compensation