Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
ribret Merge branch 'feature/update' into 'master'
Minor, only updates misspellings

See merge request stanwood/handbook!76
Latest commit 2724527 Jan 6, 2020
Type Name Latest commit message Commit time
Failed to load latest commit information.
.gitignore Update .gitignore Mar 2, 2019
LICENSE.txt Added license Aug 30, 2018 Minor, only updates misspellings Jan 6, 2020


Table of contents


We aim to be"transparent by default". We want to be equally transparent to clients and our team - both current and future. Hence the open-source nature of this document.

We also want to be an active part of the remote-work community and want to share what we've learned with other startups to bring the wonders of working as a distributed team to the world.

Update the handbook

Feel free to ask questions through issues and contribute by creating merge requests. When creating an issue, use a link to the line you are referring to for easy access, i.e.

Make sure to update the TOC after you added or edited headlines.



Stanwood exists to develop

  1. people - to become their best self
  2. teams - high performing and trusting
  3. digital products - that are useful and have impact

in that order.

We want to revolutionize how agencies operate.

Typical Agency Our aspiration
Focus: Profit Focus: People & teams
Excellence: Process design and efficiency Excellence: People operations
Recruiting: Expendable ressources Recruiting: Only hire the perfect fit that raises the team
Location: In hubs 100% distributed

Professional conduct

I. Enthusiasm & fun personality

We are fun to work with (wink)

We are outgoing, confident, charming, helpful and honest.

We communicate openly and in a timely manner.

We are not shy, hide in slack or keep grudges.

II. Time-to-market focus

We focus on shipping stuff to our client and their users.

We are super efficient.

We prefer building things over having meetings.

III. App quality

We produce fantastic user experiences.

  • Beautiful UI
  • Easy to use
  • Rock stable
  • Super fast

IV. Strong architecture and clean code

We standardise our architecture to enable fast project switching.

We actively propose changes to our standard architecture.

We write clean code. That includes

  • Separation of Concerns
  • Dependency Injection
  • Single Responsibility Principle (but not strictly adhered to)
  • Testable Code
  • Short functions - should be visible on the screen
  • Clear and understandable naming


I. Transparency and openness

We believe that transparency in itself is a virtue. The more we act in the open, the less likely we are to fall victim to internal politics or mistrust.

We also want to enable potential clients and team members to know what they are facing.


Very private

Some documents are not made public and reside in the GDrive of the MD. These are:

  1. All data considered "private" (under data protection regulations or other laws).
  2. Contracts with freelancers and employees.


Some documents are only available to team members and not the public. They reside in databases, GDrive, Candis, Debitoor, Github or GitLab. These being:

  1. Production client data - only accessible by admins.
  2. Client contracts and offers.
  3. Slack conversations - except direct messages or confidential discussions in #leads_private - we strive to discuss typically confidential topics in the open.
  4. Code and tickets on non-open-source projects
  5. Passwords and production keys (they are in 1Password).

Openness and honesty

We prefer the hard truth over mollycoddling. However, you can tell even a hard truth kindly.

We embrace numbers and data over gut feelings or single experiences.

However, we also know, that data is only a small part of the truth.

We do not misuse numbers. We know they are biased and need interpretation.


Human beings made mistakes in all of history. We are living in a world of imperfect information. We also know, that we are biased - especially when it comes to people. We therefore act on the assumption that 90% of our decisions are wrong.

We try to fail often and fast.

Failure is the best way to learn.

We admit failures - even brag about them.


stanwood is a (UK) English speaking company.

Except for very few, English is not our first language and quite frankly, we could use a bit of work on that.

All written and oral communication must be in English. Yes, even between countrymen.

We try to avoid abbreviations and industry speak as much as possible so that anyone can understand our writing. Only use jargon, if there is no equivalent in everyday English. That also helps us not to come across as pompous ;-)

We always refer to employees and freelancers as "team members" or "Woodies". New Woodies are called "Wookies" (Rooke + Woodie).

When talking about people we use the plural to avoid female or male pronouns and we try to use neutral terms where-ever possible. If not possible we alternate between female and male pronouns.

II. Hacker mindset

We work smart:

Automate everything.

Reuse existing solutions.

Do not reinvent the wheel.

We work super efficiently.

We understand the 80/20-rule.

We continuously review our tools and processes.

We believe in teamwork.

Results and time to market is far more valuable than personal credit.

III. Constant change

We always try to improve ourselves and others.

We always try to improve our processes and policies: They should help, not hamper.

We are open to new suggestions and improvements.

We try out new things early and often.

IV. Ownership

We take personal responsibility for our products.

If you find something that is broken, we make sure you fix it.

If someone must do something, we pound them into action - repeatedly.

We take personal responsibility for our tasks.

We never ignore an email or post when someone uses our handle.

We acknowledge questions or tasks within 1h in Slack or in 24h in an email.

If we cannot complete it right away, we give an ETA.

Should we not be able to hold that ETA, we inform the other with a new ETA as soon as possible.

We test and iterate our output and our processes as often as possible.

III. Love it, leave it or change it

We are hackers - we do own things the best we can despite imperfections of the outside world.

Instead of complaining, we focus on what we can control.

IV. Respect, Friendship and Support

We conduct ourselves friendly, respectfully and helpfully at all times.

But we are no family. Families exist to further relationship. stanwood exists to further our vision and strategy. Even though we strive to have the best of relationships, we let individuals go, if the are detrimental the company.

Unless someone falls on hard times: sickness, personal problems, financial issues. In those cases, we support.

We also believe in second changes and developing people. A failure in a project is never grounds for termination. Even if somebody currently does not share our vision, strategy or is not embracing our values: We do not let people go lightly. Hiring and developing teams and people is a time consuming and cost intensive process. But we also want to foster a work environment where people feel save to speak up and fail by trying out new things.

Instead we review, feedback, mentor and give second chances. Even if we decide to let somebody go, we help people we let go to find a new job and cushion the financial impact of a termination.

We embrace diversity: Nationality, language, religion, gender, sexual orientation, disabilities or mental health. We cannot have it colourful enough.

We don't disclose what someone tells us in trust.

We support each other wherever we can.

We do not allow harassment or discrimination based on age, disability, race, nationality, religious belief or lack thereof, life expectancy, sex, sexual orientation, transgender status.

We do not tolerate violent acts, threats or encouragement of violence, fighting, bullying, coercion or use of abusive or threatening words, directed to, about or against a team member, client or third party, even in a joking manner. First-time violations of this value is a fireable offence.

We kindly nudge each other should we, for instance, use the male form of a word by adding the eggplant emoji to the post.

V. Working remotely

We work where we can work best: near our families and at the places we choose, because we want to, not because we have to.

We treat each other the same - despite our location.

Working remotely can be a challenge: When someone annoys us, we assume ignorance before bad intentions.

Make an extra effort at communication.

We want to be able to work whenever, where-ever and how much we want. Towards that end we build our processes around asynchronous work, document everything and try to avoid the need for real-time communication and collaboration.

We do not discriminate based on the locations chosen by our team members. We pay the same whether you live in London or Bangkok. However, that also means, that we do not pay for travel time or cost over an average travel within Europe.


We employ the OKR goal system invented at Intel and popularised by Google by John Doerr.

To read more on the process and background on goal setting, read Measure what Matters

Company OKRs 2020

Objective 1: Sustainable growth

  • Key result: Total quotes sent out > 6 m€ @sales
  • Key result: Profitability > 30% EBIT margin @dev_teams @pms

Objective 2: Delight clients

  • Key result: Customer satisfaction > 90% (NPS) @pms
  • Key result: Sprint burn-down* > 90% @squads
  • Key result: Production/client reported bugs < 1% of total tickets @squads

Objective: 3. Become the authority on digital business and remote work

  • Key result: 200 social posts @karinkleist
  • Key result: 12 presentations held at events @hanneskl

Objective 4: Calm our operations

  • Key result: Nobody reports having being stressed very often or often in the stress survey @hanneskl
  • Key result: Reduce the number of Toggl tasks / hour to 40 @hanneskl
  • Key result: 100% of the company working < 40 h / week (including Hannes)

Squad OKRs

Objective 1: Profitability

  • Key result 1: Project profit margin > 60%, squad profit margin > 50%
  • Key result 2: # of stories > 320 @hannes
  • Key result 3: Tickets in Ready for Development/current_sprint > 30 h / dev
  • Key result 4: Maintenance contracts with all clients EOY
  • Key result 5: Sprint-based contracts with all clients for feature development EOY

Objective 2: Reliability & Quality

  • Key result 1: Sprint burn-down* > 90 %
  • Key result 2: Production/client reported bugs < 1% of total tickets
  • Key result 3: Crash production apps latest version < 0.5%

Objective 3: Become one team with the client

  • Key result 1: Responded to client mails on average within 12h as measured via intercom
  • Key result 2: 100% of client's project owner participates in dailies as reported by scrum masters via a weekly slack bot. @marcin

Platform OKRs

Objective 1: Build an eight A-level dev rooster

  • Key result 1: Performance rating of 2 for 100% team members
  • Key result 2: Create a skill matrix and assess all team members by March 1st
  • Key result 3: Create training plan to train each of the skills by by March 1st

Objective 2: Reliability & Quality

  • Key result 1: Sprint burn-down* > 90%
  • Key result 2: Production/client reported bugs < 0.5% of total tickets

Objective 3: Profitability

  • Key result 1: Platform profit margin > 40%
  • More than 90% of tickets (as counted in Ready for Development and Working on on Monday 02:00) in Done on Friday 02:00



We need to have clear policies on

  • who can decide things
  • who needs to be asked for advice
  • who should propose

Of course, we always strive to involve everyone in all discussions.

Topic Init Advice Decide Implement
Strategy Head of biz dev Everyone Owners Squad
Values Managing director Everyone Managing director Managing director
Revenue projection Managing director Squad Managing director -
Goal setting - Company & Squads Managing director Squad Managing director Squad
Goal setting - Woodie Squad Everyone Squad Everyone
Budgets Managing director Squad, Platform Squad/Managing director* -
Development process Platform Squad Platform Platform
Frameworks Platform - Platform Platform
Platform architecture Platform - Platform Platform
Security Head of tools* Platform Managing director Head of tools
Workshops Platform/Squad Everyone Managing director Platform/Squad
System architetcture Platform Squad Managing director Platform
Communication - Squad Squad Managing director Squad Squad
Communication - Policy Everyone Squad Managing director* Managing director
Travel Managing director Squad/Platform Managing director Everyone/Assistant
Marketing Head of marketing Platform/Head of sales* Managing director Marketing
Customer relations Head of sales/Platform* Platform/Head of sales* Squad Squad
Alumni Managing director Platform Managing director Platform
New squad creation Managing director/Squad* Advise Squad/Platform Managing director New squad
Recruiting Squad Platform People Ops Committee Platform
Onboarding Platform/Squad Platform/Squad Platform/Squad Platform/Squad
Personal development Squad Everyone* Squad Squad
Performance management People Ops Committee - People Ops Committee Squad
Compensation Platform Squad Managing director Managing director
Promotions People Ops Committee - People Ops Committee Managing director/Squad
Trainings Platform - Platform Everyone
Transfer Squad - Squad Squad
Termination People Ops Committee - People Ops Committee Managing director
Workshop Organisation - Company Managing director Squad Managing director Karin & Squad
Workshop Organisation - Platform Platform Squad Platform Platform
Workshop Organisation - Squad Squad Platform Squad Squad
Assigning projects to squads Managing director Squad Squad leads Squad
Project planing Squad - Squad Squad
Utilization Squad - Squad Squad
Project staffing Squad - Squad Squad
Project management process Squad Platform Squad Squad
Product documentation Squad - Squad Squad
Communication tools Squad Managing director Squad Squad
Corporate tools Managing director Squad* Managing director Managing director
Freelancer invoicing Squad - Squad Squad
Time tracking Squad - Managing director Squad
Sales Head of sales/Platform* Platform/Head of sales* Managing director Richard
Admin Managing director Managing director/Squad Managing director Managing director/Squad

Permission Management


We are facing four opposing principles when it comes to permissions.

  1. Transparency and openness by default: Every team member should be able to read and change anything.
  2. CD/CI: We need to save guard against breaking our continuous integration and deployment or production environments.
  3. Data protection: Private end-user data (databases, logs etc.) should be visible only to the smallest amount of people.
  4. We do not want a bottleneck on permissions should an admin be not available.


  1. Data protection: Production data needs to be limited to the least amount of people possible and reviewed regularly.
  2. Code and documentation: Every team member has read permissions.
  3. Our Head of Automation closely guards writing-permissions.
  4. Contact the Head of Automation in #operations in Slack if you need more permissions.
  5. Every admin permission should be with three people: MD, Head of backend development, Head of Automation.



Background on leadership

When choosing managers we consider a bunch of criteria - based on quantitative research by universities and how successful startups select and develop managers.

In particular, we are inspired by Google. Apart from being one of the most successful companies in the world, they are consistently ranked the best-place-to-work by her employees. Their mixture of employee empowerment, influences from the Montessori of Larry and Sergey and the reliance on the latest research and - of course - loads and loads of their own data truly matches our own values.

Leadership criteria

  1. Empathy: Can the lead consider the perspective and situation of the other person.
  2. Humbleness: 90% of our decisions are wrong. Act the part!
  3. Ownership: A lead sees a problem and makes it her own until it's fixed.
  4. Leadership: "Every success is due to the team, every failure is mine." and generally leading by example.
  5. Cognitive abilities: We just love people who are smarter than us. So much to learn...
  6. Grid: Only the hard stuff is worth doing.
  7. Communication: Running a remote team is x10 as hard as in an office. Exceptional communication skills (verbally, written and non-verbally) are key.

Technical skills to become a leader

We do not consider technical skills to be awfully important.

We do not promote the best "screwdriver" to run team "screwdriver". Our leads are tasked with helping the Woodies to grow as a person, becoming an entrepreneur, an amazing team member and generally an awesome human being. They shall also make the team perform better and reduce stress.

We hire only the smartest, most dedicated and fun people* and want to empower them as much as possible.

Promoting on tech skills alone will achieve exactly the opposite. With the best (i.e. Python) coder managing a team, the members would too often refer to the lead instead of making their own decisions. This inevitably leads to micromanagement and a hierarchical corporate structure.

  • Actually we want to turn the traditional hierarchy on its head. I wanna be the dumbest person. So we only hire people who are smarter or more experienced than the person who is hiring. If you doubt that, ask @paddy about the original ObjC code in ON AIR and Glamour.

Train your successor

One of the key responsibilities of leaders at stanwood is to ensure that we will always have leaders on all levels.

Because a leader might leave the company or switch to another role, the first priority for a leader is to have two members of his team which he grooms into becoming leaders themselves.

Team lead


Leadership means: "Take the blame, share the fame."

  1. As a leader, everything is always your fault. So you should still take actions to fix situations.


  • if one of your team members is unhappy or not performing
  • if a client or project manager is unresponsive, unclear in his briefings or confused
  • if a project is not running well
  • if the MD is a tyrant
  1. As a leader, you are only a facilitator. Your team does the actual work and deserves all praise.

Lead by example

  • Demonstrate our values, policies and processes every day
  • Push back on poorly described tickets and complex solutions


Improve the company

  • Proactively identify processes and policies that need improvement and push for change
  • Help the other people and leads to improve their team's procedures and policies
  • Analyse data to find patterns in our work


  • Define developer recruitments standards
  • Interview and recruit new developers
  • Push the applicants through the process


  • Coordinate project roster
  • Make sure the team is well mixed and get the chance to work with everyone.
  • Navigate and support project leads to ongoing projects.


  • Push the boundaries of your platform OS capabilities
  • Find a team member per framework and make the evangelists
  • Define and improve the company's system architecture
  • Liaison with the other platforms to align practices

People development

  • Oversee team development, and policy implementation
  • Propose promotions and developers who need review
  • Prepare and establish quarterly team review


  • Plan, organise and manage 3 annual workshops
  • Develop individualised training per team member
  • Work alongside the PM's to utilise the best working environment

Personal support

  • Support the team with any issues they have, and identify strength and weakness
  • Develop career plans for every team member

Project lead

Project leads oversee the project development, are the direct contact for PM's and manages the team to meet best coding practice, release dates, and budget.


Application Architecture

  • Propose alternative and simpler solutions, even if they do not meet 100% of requirements. Clients often accept such tradeoffs.
  • Ensure Stanwood architecture is used to reuse code and limit complexity
  • Code review to ensure code quality

Project planning

  • Make sure the ticket's description is sufficient to start development, for example:
  • Check if designs are provided
  • Check if Backend is available
  • In case of a bug, tickets check if there is sufficient data to start bug fixing like Crashlytics link, steps to replicate, info about the device
  • Check if tickets scope is not too large and break it down into sub tickets. A good rule of the thumb to ensure ticket estimate is not over 4h
  • Assign tickets to your peers to ensure optimal workload and highest chances to complete tasks on time
  • Review tickets estimations to make sure it is realistic. Not overinflated or too optimistic
  • Review and agree with PM scope of work and timelines, especially important milestones like app release.

Project execution

During project execution, you are a single point of contact for a PM for your platform. It means:

  • Proactively communicate project progress as required by PM.
  • As soon as you are aware of any new risks for project schedule, cost or quality inform PM and propose mitigation steps.

Application Documentation

  • Make sure 1password has all used secrets and password for the project.
  • Update slack channels with necessary information
  • Maintain project readme

Code review

Making sure code review is done by stanwood best practice and follow the guidelines. PR/CR Guidelines

Senior developer

As Senior developers, you have significant experience in software development, knowledge of industry practices and you are the backbone of software development at stanwood.


  • Liaise with project leads
  • Implement stanwood architecture
  • Design and implement new features
  • Push back on features that add complexity
  • Ongoing bug fixes, and maintenance
  • Keep project documentation up to date
  • Maintain and manage the existing code base
  • Liaise with project leads on new deadlines and new features

Design and implement new features

As a senior developer, you do most of the heavy lifting during development.

Push back on features that add complexity to the project lead. We are not here to solve every client feature request but look for the quickest, and safest solution that supports the code base.

Ongoing bug fixes, and maintenance

Keep project documentation up to date Work alongside the project lead and update the documentation on a regular basis.

Maintain and manage the existing code base

Make sure we are not adding technical debt when maintaining the code base. Should there be a case where the current code base does not support ongoing development, involve the project-lead?

Project managers

Order of priorities:

1. Client Communication

Keep the client close

  • Keep client informed about progress, spent budget and blockers 3x per week.
  • Send at least one personal mail a week.
  • React on average within 15 minutes to calls.*
  • React on average within 2 hours to emails, but always aim to be faster.* A short "we are on it, I will get back to you" is ok, but aim for client satisfaction.
  • React to all client requests in 1 workday.
  • Use hubspot to log all client communication (gmail connection or extension with bcc) see
  • Create tickets to all issues raised within one day.*
  • For client raised tickets, add the label reported_by_client to any bug, that the clients caught (on stage or production) or bugs we find on production.
  • During business hours.

Measure client satisfaction and improve

For all A-Level sprints:

  • Update all hubspot client properties for satisfaction once a week:
  • Update the CSAT Rating (subjective)
  • After each major release, ask the client to rate us with the NPS score (form)

2. Jira/gitlab Hygiene

Once a day:

  • Zero the inbox
  • Ping the project leads to estimate if the ticket has not been updated within the last working day
  • Ping the assignee if if ticket has not been updated for more than 1 week.
  • Ensure:
    • tickets are well described
    • documentation regarding that ticket is up to date
    • everything discussed in Slack is synced back to Jira/gitlab

3. Internal communication

  1. Offer a PM office hour for all devs 2x a day: 10am, 4pm in Post that to slack.
  2. All project questions should get cleared in this call: minimize project chatter outside these hours. Exeptions: a) Friday for building and submitting (everything goes), b) emergencies
  3. Keep your lead and all devs up to date of milestones, next milestones, of the pressing issues, blockers and goals 3x per week.
  4. Send an update post for all your projects in slack channel #done friday noon until 12:00am. Keep the post numbered and think about it as a logbook.
  5. For every project include status, blockers, next milestones
  6. is there a sprint in the following week, also include
    • if the sprint planning call took place,
    • how many hours are in the backlog for that sprint
    • and which teams attended the planning call(s) (client, dev-teams, qa).

4. Sprint steering

  1. At least every Thursday before the sprint: Grab the client and your team (including QA) and fill the backlog of the team according to the sprint planing spreadsheet. Separate calls with client if it makes no sense to have a big round with all devs.
  2. Make sure all tickets are well described before the sprint starts. All Devs should be able to work on it without further questions.
  3. After ticket creation: Tickets go to QA to add acceptance criteria, then to estimation to Dev.
  4. Wednesday: Check the burndown of the sprint, should be more than 50%
  5. Make sure the sprint burndown reaches 100% at Thursday, 23:59 CET

5. Make sure we hit 50% project profitability

  1. Check the budget with all toggl logged hours every week.
  2. Alarm your lead and team if your projects wents lower than 50% profitability rate (check the PM dashboard), and if non-coding work gets higher than 40%.
  3. Push back unreasonable and complex features. Alert Hannes, if you need firepower.
  4. Do not start before:
    1. Offer send & client signed budget
    2. Designs and Specifications
    3. Mock API from us
    4. Kick off with team & client

6. Keep documentation and Zeplin up to date

6. Upselling

Suggest features and improvements to clients. Don't sell unnecessary stuff: Offer and delight. We are inbound, not outbound.




We use Zeplin to share and discuss designs and also to host design assets and documentation for the developers.


  • Designers: Upload files there and puts sketch file on GDrive
  • Tickets live in Jira. However, only for briefing and status.
  • Commenting happens in Zeplin
    • Yellow: Todo
    • Orange: Discussion
    • Green: Documentation
  • Upload a photo and a profile picture to Zeplin.
  • Use the same handle as in slack.



We currently pay our freelancers and invoice our customers on an hourly rate and use Toggl to track time.


Let's go through the different projectsunder which you can track time. There are four main topics around which you can track time:

  1. Work for clients,
  2. Stanwood related work
  3. Squad related work
  4. Platform related work (IOS, Android, ...)

1. Project based

For each client based project, we have 7 standard categories for time tracking.

  • Client communication is mainly used by project managers it involves everything around communicating with clients: Workshops, Client meetings, calls, ...

  • Deployment is time spent getting the app live: writing App Store descriptions, ...

  • Internal communication is time spend discussing with the team: office hours, Slack, ...

  • QA is mostly used by the QA team and is everything that evolves around testing the app: smoke tests, general QA work, ...

  • Test agency is used by the QA when they review the feedback received from our test agency

  • Ticket review is time spent writing tickets, editing them, ... It is mainly used by project managers.

2. General Stanwood

For general company related tasks, we use the admin project which contains 6 categories:

  • Accounting is mostly used by the MD
  • Invoicing is for sending invoices. It is mainly used by the MD.
  • Strategy is mainly used by leads for discussions about the company's strategy
  • Zero inbox is mainly used by the MD or leads
  • Travelis only used by the MD to get a better understanding of how he spends his time.

Then, we have a few more categories that are Stanwood related

  • Marketing is for everything around content creation: social media posts, article writing, ...
  • Internal Workshops is time spent in team workshops
  • Recruiting is used for time spent interviewing candidates, replying to their emails, ...
  • Sales is used for time spend optimizing our sales funnel, communication with leads, ... anything that can help us get new customers
  • Training is for time spent learning a new skill: Udemy courses, masterclasses, ...

3. Squad related

Squad related tasks are the following:

  • Admin is for general administrative tasks related to the squad, mainly used by the squad lead.
  • Admin - Onboarding is used by Wookies (new employees/freelancers) during their first weeks for all the things they can't categorize: setting up accounts, ...
  • People Operations is for tasks like recruiting or other HR related work. It's also mainly used by the squad lead
  • Squad Meetings & Workshops is for all the meetings, calls & workshops that are Squad related. The weekly planning call for example.
  • Out of work / Nothing to do has been introduced recently and is to be used by people who have minimum monthly hours but no work to do - it does not apply to most employees.

4. Platform related

We have 5 platforms at Stanwood: IOS, Android, Web, Backend& Project Management. For each of these platforms there are three subprojects under which you can track time:

  • Frameworks is for work on frameworks.
  • Trainingis for courses, masterclasses or anything you are doing to sharpen your skills for the job
  • Workshops & Meetingsis for all platform related meetings and workshops.

The distinction between Platform work, Squad work or Stanwood work can sometimes be a bit confusing. If you have any doubts, always ask someone. Some subprojects have the same name (Admin for ex.): check the prefix to verify under which project you are tracking:

SQ0 is for Stanwood SQ1, SQ2 & SQ3 is for Squads



We use slack as our daily real-time communication tool for projects and our central non-project communication.


Add a full name, picture, phone number and email.

Username: @firstname, if taken @nickname

Same on every other platform that we use.



Official stuff. Only the MD posts here.


Post "Good morning", "be-right-back", "back", "good night" + what are you going to do today. Post "off" when you are leaving.

The first line of your post and the first emoji becomes your profile status message. Use it to communicate your availability to people who try to reach you.

When leaving for vacation, please use this template: :desert_island: on vacation, back at August 23rd.


GIFs, cat videos etc. to


General programming talks and ask for help


General project management and ask for help


PMs post status updates for all their projects on Friday before 12:00 CET. See PM internal communication for guideline.


Our very own police bot to send you reminders that require your actions from time to time.

  • Tickets that need your estimation
  • Tickets that need to be moved
  • Tickets that have are already 50% over estimate: Update the Remaining estimate and inform your pm
  • Tickets that have are already 100% over estimate: Update the Remaining estimate and inform your pm



  • When responding to todos in slack, open a thread, use "On it {time}" (i.e. "On it in 1h") and "Done"/.
  • Whenever possible, use meaningful slack reactions instead of posting an reply (example:
  • Add the handle of the person you are responding in the thread.
  • One thread per question, don't mix up two questions in a thread without a clear differentiation (e.g. numbers).


Project channels starting with "_". All real-time discussion belongs there. Jira, Zeplin, Github, Bitrise post to the project channel.


Please do not do project talk in direct messages. We lose that information to the company. Use a public channel instead. We are transparent by default, example:

When asking someone something, always use @username. Some developers are a member of dozens of channels and might miss your question.

Always use threads:

What to use slack for

  • Posting FYI information
  • Asking questions
  • Assigning non-project todos
  • Fun and giggles
  • Short discussions (max five posts)

What NOT to use slack for

  • Real-time discussions: Jump on a call.
  • Async discussions: Use Jira
  • Async questions or todos (like asking someone who is on vacation more than 1 question per channel)



We use Sketch for designing all our apps and websites.

Naming convention

  • Digit 1: Epic
  • Digit 2: View
  • Digit 3: Variant

Example: 1.1.2 Onboarding - Welcome Screen - Disabled

Storage and file versioning

We store all sketch files in the Design. The "owner" of that folder is

Fileformat: {year}-{month}-{day} {project key} {project key} {description [optional]}.sketch´ as a file name. Example: 2019-04-15 TMB Timberbase.sketch´

Try putting all designs in one file.

GDrive has a version control. Do not create versions of the file on your own.


We only use the "2019-03-12 Material Design Library" for wireframing to ensure re-usability of wireframes.

Symbols and naming

Design files need the same thought and structure as code does to ensure that we can maintain and scale a design.


  1. Your views should only have symbols in it.
  2. At the end of a design session: Clean up your symbol page
    • Ensure they are grouped together by topy
    • Ensure proper naming with paths
    • Set with elements are adjustable and which not
  3. Do not create custom design elements in your file.
    • Discuss with Hannes
    • Put them into the central template
    • Adjust the components page in the central template
  4. Structure the view: 0,0 for the first view, 0,1000 for the second
  5. Put iOS and Android side by side
  6. Use themes and font styles

Form Design Guidelines

Forms tend to be overlooked but they are actually one of the most important part of any website or app since they are what we want users to interact with. Badly designed forms lead to high churn and bad user experiences.

Pay attention to the following:

  • How will the form look like on a small screens
  • How will the form look like with/without the keyboard
  • Differences between Android and IOS design guidelines for forms (i.e. date picker)
  • Only add absolutely essential stuff to forms (i. e. you don’t need a password reset button on the registration page)
  • Forms should be designed in a way, that all UI elements fit onto the screen (with the keyboard popped out). For longer forms, use multiple screens
  • Marketing double opt-in must always be optional (by law)
  • It’s fine to require the user to approve T&Cs and Privacy Policies.
  • Passwords should be plaintext by default with a "hide" button
  • The default action button (i.e. "Proceed" or "Sign up") should always float at the bottom, 100% width, with a super bright color and above the keyboard or the bottom of the screen
  • Use customized keyboards (i.e. numbers only for phone)
  • Always reward users after major steps i.e. “Well done for signing up!”. Don’t forget to design a screen or toast that feels good to look at.
  • Requesting users to sign up (even with a "skip button") in onboarding is dangerous and will generate a high churn rate. When possible, let users browse through the app without having to sign up.

Make sure to:

  • Design a large (iPhone X etc.) 375x812 and small (iPhone SE) 320x568 resolution
  • Design a large Android 360x720 and small 320x640 resolution
  • Design with and without popped out keyboard (example can be found here)
  • Use material design guidelines for text-fields
  • Add Google/Facebook sign up buttons on registration and login screens (don’t use text links but the actual logos as in the example)
  • Have buttons look disabled (grey or 50% alpha) until all requirements of a field are met (example can be found here)
  • Put the password field on a separate view and explicitly show the password requirements and make the font colour of the requirements red initially and green, as the user meets them (example can be found here)
  • Add a progress indicator visually and verbally describing the steps required. i.e. "Step 1/4" if there is more than
  • Design helpful error screens explaining the issue and what the user should do next (example can be found here)

Background is the tool we use for quick video calls with clients or team members. We also use it for Masterclasses as it allows us to record video calls.

How to use it

  • Simply sign up with your stanwood email



We use Uber & MyTaxi to book short trips if we want to work during the trip

How to use it

  • If you've not automatically received an invitation, ask the MD.
  • When you book a trip, make sure to have it billed under your Stanwood's account

Hubspot Sales/CRM


We use Hubspot to transparently share client communications with the team, for recruiting and to schedule social media posts. Hubspot is also a powerful tool to track website visitors.
It is of crucial importance that you activate 2FA when using Hubspot.

Logging E-Mail conversations

  1. Make sure you have hubspot sales access (free is ok)
  2. Add your sending addresses to your email aliases under Profile & Preferences in Hubspot
  3. Install the hubspot sales extension.
  4. connect your gmail to hubspot or:
  5. Sending: Activate Log and Track in the compose-view when sending Mails. If it's a known contact with GDPR consent, Hubspot will add the log to the contact. If you do not use chrome (e.g. if you answer on your phones mail app), use
  6. Receiving client communication: See 4: Connect your Gmail to hubspot. If you did not connect:_ If the client did not cc is to our sales address, the mail will not get logged. Forward unlogged mails to


Note: We experiment with gitlab at the moment for a complete replacement for jira.


We use Jira as our central tool for organising our development process around tickets.

Types of Work

1. Epic

  • Group of tasks for a section in the app or topic.
  • Usually along the user flow in the app:
  • Design, Setup, Onboarding, Section 1, Section 2..., SDKs, Release
  • We try to finish epics in a development cycle so that the client and our testers can thoroughly review that block.
  • Tickets that the client actively decides not to implement or fix are assigned to the Version Later to hide them out of the backlog to keep the backlog relevant and up to date.
  • Each Epic has a link to the GitHub Documentation of that Epic.
  • Each Epic needs to have these elements: - Link to Zeplin designs - List of all UI elements - Where is the element getting its data? - Where is the aspect of writing it's data to -A list a and description of all interactions including view did appear - data was loaded successfully - an error occurred when loading the data
    • all possible user interactions

2. Tasks

Tasks have a link to the GitHub documentation and Zeplin of that Task.

3. Sub-Tasks

Tasks are broken down by the project lead into Sub-Tasks.

Each task is assigned to one platform and one developer. Tasks should not be more than 4 hours or split up into subtasks Tasks should be linked to corresponding functions on other platforms.

MUST NOT have any requirements. Those belong into the Task Estimation and logging of hours must happen on sub-tasks

4. Bugs

Clients and testers create bug tickets. Bugs must contain:

  • Steps to reproduce
  • Screenshot (ideally from TestFairy)
  • Details on the device, OS, user and state

5. Client feedback

Clients and Crashlytics create issues as "Client Feedback". The project manager details and reproduces those before changing the type to "Bug".

6. Unclear bugs

If we cannot reproduce a bug, we keep it in the Backlog as an "Unclear bug" assign the epic Later in the hope that someone can reproduce the bug.


We use versions as an additional tool to organise tickets. The rules are loose.

However: When releasing a version to testers and clients, a version must put together with all implemented tickets since the last release.


[X. Statusname [Person in charge]: Description]

Inbox [PM]: Clients and tools dump stuff in here, project managers add details

Needs Estimation [Project Lead]: Developer adds an "Original Estimate". // Suggestion: [(developer_estimation * 1.5 )+ 15%(for Code Review)]

Needs Approval [Client or PM]: Clients approves/declines.

Approved Backlog [Project Lead]: Approved by the client, but not ready to be taken by a developer in this sprint

Ready for Development [Dev]: Sprint backlog, filled by the project manager. A developer takes the ticket from there and moves to next status.

Working On [Dev]: Developer implements, (if UI-task: adds screenshots), assigns other dev to code review

Code Review [Dev]: reviewer approves, assigns author, author merges to dev, the author moves to QA with QA-instructions

QA [PM or QA Manager]: Project managers: reviews or asks QA-Manager to review. if failed: Assigns back to the author working on if approved: moves to client review (if no client: done)

Needs client review [Client]: Client approves/declines

Done [PM] (Won't fix [PM]: Tickets, that are not solved and need no further attention) (Duplicate [PM]: Duplicates, need to be linked to the original first) Crashlytics Issues

The PM should create a bug ticket and add the issues link in the description.

The developer should close the issue on Crashlytics once he fixes a bug and the ticket moves to Prio: 'Blocker' We use this to indicate that we cannot proceed with a ticket due to something missing by someone else. i.e. an API to be finished or a design to be created.

The project manager reviews those blockers regularly to check if the constraint has been lifted.


Discussions on issues belong in the comments in the issue. If we discuss something is discussed in slack or a call, the project lead is responsible for summarising the decision on the ticket.



We use Github/gitlab to host our code.

Gitlab Structure

Although gitlab is currently only under consideration we use the following structure of groups

/handbook (the handbook)

/internal (internal documents)

/open-source/{project key} (open source projects)

/apps/{client key}/{project key} (client projects)

The first project in any project group is documentation where we host all relevant documentation in the wiki for description and the repo for content where we want version control - for instance when using merge requests to inform the team of changes in data structure by assigning them as approvers.


We are using a custom Gitflow.

Perennial branches

  • master: deployed versions
  • develop: clean development version, for testing and beta release
  • stage: merged from develop for testing (not on Android)


  • Never push or merge directly into master and develop. Only reviewed pull requests are allowed to be merged.
  • All feature/hotfix branches must be merged into the release branch via pull requests during the sprint
  • Commit & push approx. all 3 hours
  • Create pull request for every issue before you move to "Code Review" and assign the reviewer in GitHub
  • On "go live": Project lead merges to master, creates a tag and adds release notes from Jira


For Jira and Toggl to auto import the code changes, we need to follow some naming conventions.

  • Pull request:
    • github: SEL-123 {Ticket description}
    • gitlab: #123 Ticket description
      • reference the ticket in the description as well, e.g. "See #123" to have an easy to use backlink to the original ticket so that the reviewers can check the ticket contents and can enable time tracking on that ticket.
      • Remove the default "Closes #123" as it will close the ticket right after merging which is NOT what we want
  • Branch:
    • Use - for whitespaces in the branch name (just as gitlab does when it auto-creates the branch for you), don't use _
    • github: feature,hotfix,bugfix/SEL-123-{ticket-description}, e.g.
      • feature/SEL-12-awesome-feature
      • hotfix/SEL-13-awesome-hotfix (fixing something in master)
      • bugfix/SEL-14-awesome-bugfix (fixing)
    • gitlab: 123-{ticket-description} (best create the branch directly from the ticket via the web UI and then check it out locally)
  • Commit:
    • github: SEL-123 {commit description}
    • gitlab: #123 {commit description}

ticket-description in branch names does not have to be the same as Summary in Jira/gitlab as there can be multiple branches per ticket. You can rephrase it as long as the meaning does not get lost.

Code Review

PR/CR Guidelines

Only use GitHub comments for the initial and short discussions. More extended discussions should happen in Slack (public project channel). Report the results (+link) of that discussion in GitHub.

When we add new libraries which have not been pre-approved via the library list, please include one of the following developers as a reviewer and describe why you used that particular library (and what possible pitfalls it has) in the PR description.

Mandatory reviewers

iOS: Tal

Android: the project lead

Web: Arni


E-Mails are slow (having to add all those "Hi there, kind regards") and get un-readable when more than 2 people start responding in a thread.

Also, you cannot leave a thread.

  1. E-Mails are not allowed for internal communication - except during vacation and to forward attachments like invoices.

  2. When forwarding documents, never zip them. Always use

  3. Learn about filters and search suffixes in Gmail.



Bitrise is our CD/CI for Android and iOS apps.


  • master and develop must always build
  • master deploys to App Stores or production web server
  • develop deploys to clients Monday 9 am



1Password is where we store all our logins.

Chrome Extension

1Password has a very handy Chrome extension, make sure to use it!


  • Private is where every team member can individually store all their private logins to company accounts (Toggl, Hubspot, ...)
  • Company Accounts is where our team can access all our shared accounts (Udemy, developer tools, ...)
  • Payments is where our team can access our company cards (We limit access to that vault on a need to know basis.)

For email addresses that contain sensitive information, they are in other hidden vaults.

Chrome Extension

1Password has a very handy Chrome extension, make sure to use it!


  • Private is where our team can store all their private logins to company accounts (Toggl, Hubspot, ...)
  • Company Accounts is where our team can access all our shared accounts (Udemy, developer tools, ...)
  • Payments is where our team can access our company cards

We give our employees access to vaults on a need basis for security purpose.

Core processes

Developer Operations

1. Background

We love to develop apps and websites which will be loved by users and clients.

We want to be transparent and dependable for our client. We also want to sync crowd testing and processes of our clients as well as reduce misunderstandings and unclear tickets.

At last, we want to limit crossfire from clients throughout the week and "jumping" in and out of projects.

2. Staffing

We staff every project.

  • With a project manager
  • One platform lead and one (or more) supporting frontend developer per platform
  • One (or more) backend developers

3. Timing and Budget

We practice Rapid Software Development. We aim to get apps to the store within 8 weeks after the briefing.

  • week 1: concept, wireframing and architecture
  • week 2: design, estimation, setup
  • weeks 3-6: coding (3 development cycles)
  • weels 7-8: testing and fixing (by crowd and client)

Overhead: We should not spend more than

  • 15% on project management (including the project manager!)
  • 15% on fixing bugs after releasing the first beta
  • 15% on QA and testing
  • 15% on refactoring

4. The Development Process

Weekly cycle

  • Project manager moves the weeks worth of tickets to Ready for Development before Friday noon.
  • Weekly staffing and update meetings on Friday between project managers and team leads
    • What did we achieve/not finish last week?
    • Which epics are we tackling this week?
    • Roadblocks: We raise them. However, do not solve them.
    • Solving staffing issues and bottlenecks
  • After: Team and project leads go through Ready for Development and delegate tickets to the team
  • Development
  • Developers: Implement and review all tickets from the development cycle ready for development till Thursday evening.
  • Project manager/QA managers: Reviews all tickets on develop branch and report bugs.
  • Developers: Fix those bugs.
  • Project leads to ensure that develop is working and testable build deployed to TestFairy
  • QA manager reviews the feedback from the testing agency and creates bugs tickets in Jira.
  • Project manager distributes the test version to the client with release notes for review

Ticket life-cycle

Tickets always need to include a billable or unbillable label to insure the accuracy of our revenue reports.

  • Project manager creates a ticket, adds the relevant description and moved to Needs estimation and assigned to Project lead
  • Project lead reviews the ticket for sufficient information and estimates 1h/ 2h/ 4h
  • Once estimated, the ticket is moved to Needs approval and assigned to project manager
  • Project manager (or client) approves, moves the ticket to Approved backlog and assigns the project lead
  • On Friday, planned tickets for the following sprint are moved to Ready for development.
  • The developer grabs an assigned ticket in order of priority and moves to Working on.
  • Once the ticket is complete, the developer creates a Pull Request assigned to the project lead and moves the ticket to Code Review.
  • Project lead approves the PR and assigns the ticket back to the developer
  • [GitLab Flow] The developer moves the ticket to QA when the branch is merged to develop and assigns the QA manager to test the ticket
  • [GitHub Flow] The developer moves the ticket to QA and assigns the QA manager to test the ticket on the separate URL (specific for this ticket).
  • [GitLab Flow] The QA approves the ticket and moves to Done; the original developer is assigned again
  • [GitHub Flow] The QA approves the ticket, merge Pull Reqest and moves to Done; the original developer is assigned again
  • The QA manager moves rejected tickets are moved to Ready for development.


The person responsible for the next step must be assigned to the ticket. i.e. when asking a question that question that blocks the ticket, please assign the person you asked.

Order of work: Weekly priority sent up until Monday; Priority: Critical, Status: Needs estimation, QA, Code Review, Working on, Ready for Development

All tickets must receive

  • Code review
  • App/web: a functional review by the Project manager or QA manager
  • API: a functional review by front-end developer

Pull requests

  • Developers create a pull request from their feature/hotfix/bugfix branch to develop branch.
  • Assigns the Project leads for code review on GitHub.
  • Project leads reviews code and approves PR (reviewer is not merging PR)
  • Author of pull request merges to develop and moves the ticket to QA.


The project lead developer creates a testable version on Friday EOD.

A QA manager ships a testable build to the testing agency. Each release is tested by internal testers or our test agency over the weekend.

Client feedback

The client gives feedback throughout the week (report bugs, adds request changes). For that, they are invited to do that directly in Jira.

Only tickets we get till Thursday can be part of the next development cycle.

Project managers review, reproduce and detail client requests/bug reports and creates and details Epics, breaks down to Tasks and coordinates priorities with the client on an ongoing basis.

The project lead breaks down Tasks to sub-tasks for each platform and create API sub-task tickets, estimates sub-tasks and tasks (if no subtasks) and moves them to Needs approval.

Release policy

Major/Minor Release

Monday-Wednesday. Thursday if critical.

Hotfix Release

Hotfixes on a Friday, only if 10%+ users are affected.

Major Releases

Are used sparingly — only 1-2 major releases per year.

1.0, 2.0, 3.0

Minor Releases

Every release with features in it increments the second digit of the version.

1.1, 2.3, 2.5

Hotfix Releases

Releases that merely fix bugs are incremented with the third digit of the version.

1.1.1, 2.3.4

Build numbers

We use automatically increasing build numbers from Bitrise. We use the same build version as Bitrise build.


Ticket live cycle

Topic Project manager Project Lead Developer
Ticket description Implement Review
Estimation Decide
Creating subtasks Refine Advice
Push back on complexity Advice Advice
Release dates Refine Advice
Delegating tickets Decide
Architecture Enforce Implement
Review code Review

Project setup Android

  1. Ask Martin to create a new repository
  2. Check out the repository
  3. Create a new app in the checked out repository
    • In the create-app-flow select Fragment + ViewModel (package is feature..ui)
    • Add Kotlin support
    • Select API 21+
  4. Add Navigation Components and convert MainActivity to use navigation to load the first Fragment
  5. Add /.idea/navEditor.xml to gitignore
  6. Set compile options within Android:
compileOptions {
	sourceCompatibility JavaVersion.VERSION_1_8
	targetCompatibility JavaVersion.VERSION_1_8
  1. Add data binding in app's build.gradle:
dataBinding {
	enabled = true
  1. Configure build types:
buildTypes {
	stage {
		matchingFallbacks ['release']
		minifyEnabled true
		proguardFiles getDefaultProguardFile('proguard-android.txt'), ''
	release {
		minifyEnabled true
		proguardFiles getDefaultProguardFile('proguard-android.txt'), ''
  1. Configure bitrise
  2. Set up Code Style.
  3. Set up architecture (general, DI etc.)

Code Style Android


All our projects follow the Android Kotlin Code Style (with one exception: line length 140 chars) for all Kotlin classes. We use ktlint for automated checks.

To make our lives easier we use the ktlint-gradle-plugin.

In your project build.gradle:

buildscript {
  repositories {
    maven {
      url ""
  dependencies {
    classpath "org.jlleitschuh.gradle:ktlint-gradle:<current_version>"

apply plugin: "org.jlleitschuh.gradle.ktlint"

subprojects {
    apply plugin: "org.jlleitschuh.gradle.ktlint"

Then create a file called .editorconfig in the root of your project:

[*.{kt, kts}]
max_line_length = 140

Make sure to now run ./gradlew ktlintFormat and fix all issues popping up.

Don't forget to set up your IDE and bitrise as well

Android Studio and git integration

When importing an already existing and ktlint-enabled (see section above project you need to configure Android Studio to comply with the code style as well (this needs to be done on a per-project base by everyone who wants to work with ktlint enabled projects:

Just execute the following two calls to configure your IDE and git for this project and add a pre-commit hook to do the checking (and if necessary formatting for you):

./gradlew ktlintApplyToIdea
./gradlew addKtlintFormatGitPreCommitHook

Make sure to check the Run Git hooks checkbox if you commit via Android Studio (should be set by default).

Last thing to do is setting line length to 140 (Preferences -> Editor -> Code Style) - unfortunately ktlintApplyToIdea can't do that for you.


Add the following step to your workflows to have bitrise check your code style as well:

	- gradle-runner@1.8.4:
	    - gradle_task: ktlintCheck
	    title: ktlint

Additionally make sure that you have defined the following environment variables:

	- opts:
      is_expand: false
    GRADLE_BUILD_FILE_PATH: build.gradle
	- opts:
		  is_expand: false
		GRADLEW_PATH: "./gradlew"

Release Procedure Web Projects

1. During Development

During the week we merge feature/bugfix branches into develop.

The CDCI auto-deploys to the develop environment.


  • @devs: Codes, creates PR and merges
  • @project lead: Approves PR
  • @qa: Test features on develop.

2. Creating a testable version

Thursday evening develop is merged into stage to have a stable environment for QA, test agency and client approval.

The CDCI automatically deploys to stage environment.


  • @pm: Decides on time and date
  • @qa: Gives the green light
  • @project lead: Merges
  • QA: Do smoke testing
  • Test agency: Smoke testing
  • Client: Smoke testing and approval

3. Go Live

Between Monday and Wednesday, we deploy to production by merging stage into master.

CDCD auto-deploys to production environment.


  • @pm: Decides on time and date.
  • @qa: Give green light.
  • @project lead: Merges.
  • @qa: Do post-go-live smoke testing.


Always keep the project documentation in confluence up to date before moving your ticket to QA.

We document EPICs in confluence and only link from Jira tickets.


1. Jira Epic

Link to Jira Epic

2. User stories

List of included user stories = functional requirements (describe what’s in scope)

List of not-included user stories (describe what’s out of scope)

3. Requirements

List of non-feature requirements

4. Architecture

Description of API components, i.e. firebase, GAE, 3rd party APIs with links to documentation


List of all views with different platforms and screen resolutions with links to Zeplin

Name Link

6. Tracking

7. Links

Add link, that only links that pertain to this epic.

8. Todos

Non-ticket todos

API Guidelines

Permissions & Setup

IMPORTANT: Only the backend team is allowed to create firebase, contentful or GAE instances.

They do that via a script that ensures all our policies are enforce.

If individuals set up those instances, they forget imortant security or permissions policies and endangering our operations or even clients data.


The decision for an API can have tremendous implications for the overall effort (and pain) of developing frontend. We have seen projects exploding 10x because of APIs we had no control over.

Preferred solution: 100% control

1. Own API

When we need a complex backend, our fearless backend team build a rock solid, high performance, super scalable, 100% unit tested and monitored thing of beauty on Google App Engine in Python.

2. Firebase

For smaller projects and prototypes that only need lightweight auth, data or file storage we use firebase.


  • Do not need a backend developer to build things
  • The real-time database can function as a mock API (supports most HTTP methods including POST, PUT and DELETE)
  • Changes can be monitored in real time
  • Super easy integration
  • Real-time database


  • Firebase has no build in server-side logging and makes debugging a pain
  • Changing data models is virtually impossible
  • Data can be broken super fast - esp. on production
  • Analytics on the data structure is hard

Third-party APIs

Should clients force us to use a 3rd party API or one they are building, we always build a proxy.

The front-end developers then draft the API as they would need it.

The proxy then translates between the frontend API and the 3rd party API.


  • Frontend development gets a highly optimised API
  • We can monitor the 3rd party APIs for errors and report that directly to the client.
  • We can hit cache and prevent outages even when the client APIs breaks.


We use Stackdriver to monitor for outages, errors and speed of the API itself and Runscope as well as Postman to mimic user requests to do a full end-to-end test of the API every few minutes.



Web Gitlab

Gitlab CDCI Web Guidelines


0. Get the project deploy from your local terminal

1. Set up variables in settings/cd_ci


The central token is in 1password.

Do not protect them the variables. Otherwise, they are not be passed to the develop and stage branch.

2. Set up CDCD file in root

Add a .gitlab-ci.yml file on develop, then merge down to stage and master.

Be careful! This will deploy to production.

image: node:latest

  stage: test
  environment: develop
    - develop
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=$FIREBASE_PROJECT_DEVELOP --only hosting

  stage: deploy
  environment: stage
    - stage
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=$FIREBASE_PROJECT_STAGE --only hosting

  stage: deploy
  environment: production
    - master
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=FIREBASE_PROJECT_PRODUCTION --only hosting

3. Todos

  1. Use cached folders to speed up deployment time
  2. Gitlab wants testing (develop), and deployment handled differently. Research how that is done.
  3. Use a centralised CDCI file to save config time.
  4. Which firebase token should we use?
  5. Create artefacts. Ideally, we can download a working snapshot of the build.
  6. Review if all those steps are required or if we can skip some 7. npm install -g npm@5.6.0 8. npm install 9. npm run build

People operations



As we grow the complexity of operating the company grows. To run our company efficiently, every new team member must raise the bar. Towards that end, every recruit must be better than the median member than that team.

Preferably every recruit is better than any member of that team and especially the manager of that team.

We are acutely aware that hiring - as all people related questions - is a profoundly biased process. In addition to that, bad hires are very costly both financially and culturally.

To remedy those biases we created an elaborate process with multiple steps and at least 5 interviews.


See our private recruitment section.

Note: This information is private, as they contain tasks candidates need to solve and questions they need to answer.

Being able to prepare in advance defeats the purpose.


As we have access to clients production databases, we are subject to data protection laws, non-disclosure-agreements and data-processing-agreements with all our clients.

In those contracts, we are responsible for enforcing the same clauses to all our team members.

Every freelancer and employee needs to sign 3 documents:

  1. Non disclosure agreement: Template
  2. Data processing agreement: Template
  3. Core contract 4. Freelancing contract: Template 5. Employment contract: Template

We only use digital contracts via DocuSign. Paper is a pain.

Freelance vs. Full time employee

We prefer working on a freelance basis because of this.

  • reduces the accounting and admin overhead by 90%
  • captures our entrepreneurial spirit
  • is closer to our processes

Some countries have "fake-freelancer-laws" that prohibits this practice sometimes. In those cases, we go with the employment contract.



We provide a transparent and unified payment scheme based on hourly rates that reflect the impact for the company, responsibilities and scarcity of the skill set.

Developers and project managers

  • New guys: 25€
  • Mid-level: 30€
  • Senior: 35€
  • Project lead: 40€
  • Team lead: 45€

QA manager

  • Junior: 15€
  • Mid: 20€
  • Senior: 25€
  • Team lead: 30€

We do not downgrade existing hourly rates. We will heal the existing "injustices" with a general rate increase or our team-member-profit-share program in the next years.

Full-time employees

Full-time employees get a wage based on the gross cost hourly rate + 20% (employer payment for pension health insurance, ...) x 8 h / day x 220 d / year.

So if an employee and a freelancer work that 1760 h per year, they cost the company the same amount.

220 d is the average per full-time employee in Germany.

1700 h was the average of full-time freelancer at stanwood last year.



Wage: 40 €/h x 8 h/d x 220 d/y x 80% = 56,320 €

Benefits: 40 €/h x 8 h/d x 220 d/y x 20% = 14,080 €


Fee: 40 €/h x 8 h/d x 220 d/y = 70,400 €


Headspace Subscription

One of our goals is to reduce stress level and help ourselves with mental health issues.

For us a mental health issue is just a health issue as a broken arm or a cold - although tougher to heal from.

Towards that end do we offer every team member and alumni a free subscription to the meditation & mindfulness app Headspace.

Hot desk in the coworking of your choice

Being remote, we obviously don't have an office anymore. While a major part of our team works from home, we know that some people prefer working in a coworking.


New team members (aka Wookies) need these accounts.

All accounts (except GitHub and Gitlab) must be the email.

0. TODO Wookie / new employee

Ask them to read this handbook thoroughly!

1. E-mail

Create an e-mail

Lead sends a password to private email or mobile phone of the user and asks new employee to change PW right after logging in.

All following invites (if not mentioned otherwise) go to that new Email address.

2. Slack

  1. Add user
  2. Add user to group

The new handle will only be usable after registration.

ToDo Wookie Choose username by following Guideline guideline

3. Github and Gitlab

Add private and handle to teams if handle already exists.

ToDo Wookie

  • If you have no account there, create new account and send your username to your lead
  • enable 2FA

4. Toggl

  1. Add user
  2. Add user to a group (used in accounting)

5. Jira

Username: Only the first name

Add to the group: "Developers."

6. 1password

7. Zeplin & Invision

8. Holiday Calendar & All Hands Meetings

Add user to Group

User will be added to the Holidays calender and All hands meetings

9. Applause

10. Add birthday and anniversary to Hannes Calendar and Spreadsheet

11. MyTaxi

12. Trello


14. Zoho

Teamlead adds Wookie to zoho people.

ToDo Wookie Update your info in

Zoho Expense (Employees only) Employees expense with zoho expense.

15. Bitrise

ToDo Wookie If you have no account there, create new account and send your username to your lead

16. TODO for Wookie: Setup Jira/gitlab + Toggle Sync:

Install and configure our own Toggl Chrome extension fork:

New devs: Enable Toggl + Jira Sync, please: (still needed with the aforementioned?)

17. For PMs only: Hubspot Use 2FA!

18. Add them to our Shared GDrives

Shared Drives

19. After they accepted everything:

Add them to the project and general slack channels. Welcome them in #general

Continuous Performance Management

1 on 1 reviews

We do continuous performance management. Leads have regular 1 on 1 reviews with their team members.

We centre on these questions:

  • What are you working on?
  • How are you doing?
  • How are your OKRs/Goals coming along?
  • Is there anything impeding your work?
  • What do you need from me to be (more) successful?
  • How do you need to grow to achieve your career goals?

This is the team members meeting. Tone and agenda should be set by the team member. The lead is there to coach and learn.

Background information:

People development


stanwood is the embodiment of change. We want to improve every day. One crucial step (others are Analyses, Planning, Doing and Collecting Data) is the Review.

1. Personal development review

Every team member has a personal development review meeting with their team lead four times per year, where we review 360° feedback.

Apart from general feedback, your lead discusses these points:

  • Developer ideals
  • Team KPIs and how you might contribute
  • 360° feedback

With the Q1 feedback in 2019, we add personal goals and personal KPIs.

1. Goals

Numerous studies have shown, that setting goals increase a teams performance and personal happiness.

We already have our company goals for each year.

We start developing (bottom-up) goals for every team in 2018 and every person in 2019.

Those goals can - but must not overlap - with the higher team and company goals.

Goal achievement is purely developmental and is not tied to your compensation or career.

2. KPI

We are blessed with numerous sources of data that can help us understand our performance as a group.

When setting goals, we try to use data to inform our decision making.

We also use data to identify patterns and improve our operations.

We never use data to control or punish people.

KPIs are purely developmental and are tied to your compensation or career.

Developer KPI

  1. Estimation accuracy
  2. Feature implementation speed
  3. Bug fixing speed
  4. % worked on bugs vs features
  5. % tickets passing QA on the first try


  1. % tickets passing QA on the first
  2. Total number of tickets reviewed
  3. Number of bugs found by the client

Project management KPI

  1. Estimation accuracy
  2. % worked on bugs vs features
  3. % tickets passing QA on the first try
  4. Project profitability

3. 360° Feedback

We want to give you a fuller picture of how you are perceived by our fellow Woodies and even clients (for project managers).

For that end, we identified up to 7 people each Woody worked with most - that gives anonymised feedback and vice versa.

This survey is purely developmental. Nothing you say here impacts compensation or the career of that person or yours.


Please choose your feedback partners from this list Pairings

moreover, leave them short and actionable feedback here



Keep "Fun to work with, a good mentor, always available to help when I have technical issues, or I am blocked with a task."

Change "Share more from his/her experience in programming channels so I can learn, delegate more interesting tasks where I can improve my skills, "


  1. This survey is anonymous towards the person you give feedback.
  2. Hannes sees all answers and your name.
  3. Team leads see all answers for their team and your name.
  4. The team lead synthesises all feedback to ensure anonymity.
  5. If you do not have 7 people on your list, click "NEXT" and leave those sections empty.

4. Leadership feedback

Our team leads get a bit more detailed feedback. Every team member answers the following 12 questions.

  • My team lead gives me actionable feedback that helps me improve my performance.
  • My team lead does not "micromanage".
  • My team lead shows consideration for me as a person.
  • My team lead values the perspective I bring to the team, even if it is different from his own.
  • My team lead keeps the team focused on our priority results/deliverables.
  • My team lead regularly shares relevant information from his bosses.
  • My team lead has had a meaningful discussion with me about career development in the past six months.
  • My team lead communicates clear goals for our team.
  • My team lead has the technical expertise required to effectively manage me.
  • I am satisfied with My team lead’s overall performance as a manager.
  • What should My team lead keep doing?
  • What should My team lead change?

This is based on Google's research what kind of leader makes teams most effective.

Performance Management

We will be introducing a separate performance review process in 2019 because of the following occurrences from 2018/2019.

  1. Team members quit because or rated our compensation and promotion policy as unjust across teams.
  2. Team members were surprised when we let them go because they were not aware that their performance in the company did not match our expectations.

When stanwood was just ten people the managing director could talk to everyone in the company enabling

  1. Fair and calibrating compensation and promotion
  2. Explain every decision
  3. We also did not let people too because we valued relationships more than performance and impact on the team or clients.

stanwoodgeist survey

We want to create the best place to work. In a growing company it get's harder to get everyones feedback and synthesise that up the chain of command. Some feedback we never get despite our best efforts. Either because it's too personal, the team member does not fully trust their manager or just because they are too shy in general.

To get a comprehensive picture on how we see the company on various aspects and identify areas of focus on, we sent out the stanwoodgeist survey every 6 months covering topics around

  1. Work
  2. Culture
  3. Leadership
  4. Fairness

TODO: @hanneskl: Add questions here



We want to get better at what we do every day. For that we offer the following tools:


We pay both hours and courses for everyone to learn any (really any) of the trades that we use at stanwood. If you are a coder, who wants to learn to design: You are welcome — a QA manager who wants to learn Accounting: Yes, please.

Just ping the MD or your team lead, and we set you up.


Every Wednesday at 10 am CET we hold a masterclass where one of our own gives a 30 minute talk (strictly enforced) about an exciting topic.

All masterclasses are voluntary.

We use record those classes for later consumption.

Check #masterclass for more info.



We meet 2x per year for a two-day workshop.


Between the retreats, teams can meet as often as they see fit.

Grill the boss

Every week the managing director invites one Woodie to fly to Munich and spent an evening cooking and drinking. Every new team member is invited in their first two weeks.

Woodie can ask all the deep questions and meander with the Supreme Mugwump about vision, strategy and all things geek.

All expenses paid of course.

Meet a Woody

If a Woodie wants to meet another Woodie in person, we are sponsoring the flight with up to 200€ and a stay at the hotel up to 100€.

Send a direct message to the MD and explain why you want to go.

We will be generous.

The visit can be be project related or just because a Woodie always wanted to meet the other person.

Groups are also allowed, for instance, to do a team kick off or celebratory launch party.

Travel and Expensing


We try to minimise the accounting overhead of traveling as much as possible.

Every Woodie get's a company virtual credit card via and is responsible to adding the recipts to Pleo.

Sales, consultants and leads get real credit cards to pay in restaurants.

Booking process

All travels are organised in Trello.

  1. When we need a travel, we create a card in "Planing".
  2. Add a location, attendees, dates and required actions in a checklist and assign who is responsible for it.
  3. As soon as everything is booked, our office manager moves the card to "Booked"
  4. After the event, the main attendee writes a quick summary (optional) and moves to "Done".

Then add your flight times to the holiday calendar with "{my name} {flight number}", in order for the organisers see your flight times.


Our office manager books hotels in #office centrally for everyone. Invoices are paid by the company via credit card.


Every team member books and pays their flights, train rides or car trips themselves with their company credit card and expenses them.


When two Woodies meet or meet with a client, the company pays for food.

What we pay for

As a general rule: You are a guardian of the company. We trust you to make the right choices and spent our money wisely.


  • Economy class on first tier airlines (Lufthansa, BA, El-Al)
  • We try to do direct flights only - outside business hours to minimise cost, stress and lost work time
  • Feel free to upgrade your seats to emergency exit row, if you are want to to work
  • Frequent travellers (30+ flights per year) may book business class


  • Business or first class if you want to work
  • Economy class if you want to chill


  • Motel One
  • London: Pullmann

Conference Rooms

  • Wework, Business Link or Mindshare

Food & Drinks

We do dinners burger-and-beer-style. Anything fancy needs prior approval by the MD.

Food during events

  • We have breakfast at the hotel
  • Lunch is paid by the company
  • Dinner is paid by the company
  • Drinks are paid by the MD (if present) (Note: This is not tax-deductable.)

Time Tracking


We (mostly) invoice our clients based on hours worked.

We get paid by the hour. Our clients honor us with a tremendous amount of trust - in return we give them total transparency.

Update 2019: We are reworking this part. We want to get rid of time tracking as much as possible to reduce our stress level.

They expect splits by ticket or overhead tasks.

Working hours

When you work is up to you, but make it transparent to the project team, and the team leads. But you must make sure to be able to react during CET hours.

Make sure to answer all messages in slack at least within 1h during 10:00 and 18:00 CET. This is only required if you have not marked the day or period in the Holiday calendar. See the chapter on Slack for details.

Public holidays and vacations

Use the GCal Holiday calendar to put in your vacations. A 4-week head start would be good, so the leads can plan the projects.

Check with the PM that we have no releases or major events planned during that time.

Also make sure, that the developer from your platform / other PM is not on vacation as well.

Post in #status, should you be away from the keyboard for more than 1 h during 10:00 and 18:00 CET


When participating in or preparing for a workshop book on "Internal Workshops".


We do not pay for the time you spent travelling, so please do not book it.

However, if you bring your laptop and work while on transit, please usually book on the project, and you will, of course, be paid.


Please book the time for participating and preparing for Masterclasses on "Internal Workshops".

Marketing / Content

Marketing, writing articles and posts or work on our own website are tracked on "content"


If you are a wookie in your first onboarding-weeks, you can book onboarding time on "onboarding".


When you are helping with a pitch or a sales presentation, please book on project "Sales".


Use the Jira ticket ID and description, i.e. LEN-01 My awesome new feature Assign a project.

Best do it realtime. Use Toggl-Jira chrome extension

Book non-ticket project work on one of the Tasks in Toggl:

  • Client communication
  • Internal communication
  • Estimation
  • Ticket review
  • Test agency
  • QA
  • Testing
  • Deploying

On invoices they get mapped to

  1. Added pro rata to tickets

    • Internal communication
    • QA
    • Testing
  2. Consulting

    • Client communication
  3. Concepting

    • Estimation
  4. Project management

    • Ticket review
  5. Review test agency

    • Test agency
  6. Deployment

    • Deploying
    • Service Desk

Book non-project work on project Travel & Admin. Always book project work on projects.


We strive to be a company that does not have to fire people.

However, even the best hiring and people development process fails from time to time, and we have to part ways with a person.

We give feedback at least every 6 months during our performance reviews.

There are 5 main reasons for ending or not extending a contract:

  1. Gross negligence or malicious behaviour hurting a client or the company
  2. Hurting another Woody or poisoning the team athmosphere
  3. Not following our vision and values
  4. Long term under-performance with no improvement through coaching.
  5. Financial strains the company cannot overcome
  6. The employee asks us to end the contract


This process is only valid for reasons #3.

#1 leads to immediate termination without any severance package

For reasons #2, #4 or #5 we only honour the contracts.

  • The team lead and the MD decide to start the process.
  • All team leads discuss the issue.
  • Team leads have a veto that the MD can override.
  • The Woodie is told by his lead with Hannes present, that he/she is officially on-notice for four weeks and what changes are required to stay in the company.
  • Daily check-ins with Hannes and the respective lead.
  • After 4 weeks the leads and Hannes review the process and decide to either
    • End the contract
    • Extend the contract
    • Extend the on-notice period by another 4 weeks
  • The employee is told the decision by the Lead with Hannes present
  • Hannes will inform the company about the decision and the reasons
  • Should the contract be ended, we offer a 4 week grace period during which the employee gets full pay
  • The developer must show 200% commitment during those 4 weeks including reporting every ticket when they start and end working on to the team lead and project manager
  • stanwood uses all their contacts to find another engagement for the developer

Last day


  • Disable all accounts from on-boarding


  • Write a personal note to the person leaving
  • Thank the person on #general

Person leaving

  • Reply to MD post with a personal message to the team and leave your private email to stay in touch [Optional]
  • Remove stanwood GDrive
  • Remove all accounts and passwords from password manager
  • Remove all code repository and stanwood docs from your computer
  • Remove all private data from your computer [if company computer]
  • Reset all devices to factory settings [If company hardware]
  • Sent hardware back to MD [if company hardware]
  • Sent last invoice (if freelancer)


Every team member who leaves the company on his accord will become part of the esteemed club of stanwood alumni.

Stanwood Alumni Perks

As a Stanwood Alumni, you:

  • Keep your email and slack account
  • Get invited to all company retreats and workshops (travel expenses are paid but not the hours).
  • Can keep using your Private 1Password Vault

Support processes


Tools & Processes

All ingoing an outgoing invoices are digitised and then sent to (alias of

That forwards it to for processing.

Payments are made every Monday morning from and the local tool MoneyMoney by the MD.

On the next Monday that is not the 1st of the month is closed.

The MD adds cost centres and accounts numbers to all invoices.

Our accountants (Goldstein Consulting) get an export of all data, do some accounting magic and create cost centre reports for all teams.


Every invoice gets 3 tags.

  1. Type: i.e. Travel (0..9,999)
  2. Company: i.e. Uber (10,000..99,999)
  3. Cost center 1: i.e. Team android (1000..999,999)
  4. Cost center 2: i.e. Squad 1

Cost centres

Every lead is responsible for a cost centre.

  • 1000 General Management @hannes
    • 1100 Sales & Marketing
      • 1110 Sales @richard
    • 1200 Finance
  • 2000 Product & Project Management
    • 2100 Project Management @richard
    • 2200 Quality Assurance @richard
  • 3000 Software Development
    • 3100 Mobile Development
      • 3110 iOS Development @tal
      • 3120 android Development @milosz
    • 3200 Web Development
      • 3300 Backend Development @marcin
      • 3400 Web Frontend Development @arni
  • 4000 Operations
    • 4100 Hosting @marcin
    • 4200 Tools @hannes
  • ~~5000 Squads~~~
    • 5100 Squad 1 @marcin
    • 5200 Squad 2 @tal
    • 5300 Squad 3 @richard

Freelancer Invoices

Invoice needs to be in German or English. Can have your language as well.

Required elements

  • Full name of the company or freelancer
  • Full address of the company or freelancer
  • Full address of stanwood (take from website imprint)
  • Tax ID or VAT ID even if there is no tax applicable
  • Date of the invoice
  • The month of service provided (usually the prior month
  • Invoice number: Incremental
  • Hours worked and hourly rate
  • Description i.e. "Software development", "consulting"
  • Add extra lines for travel expenses
  • Net sum
  • VAT tax rate and sum (usually 0% and 0€ because of reverse charge)
  • Gross sum (net + tax)
  • If reverse charge
    • add "No tax due to reverse-charge."
    • add "stanwood VAT ID: DE 321356612".
  • IBAN and BIC

In Germany, you might be a "Kleinunternehmer". Check with your accountant and then add this to your invoice:

 "Als Kleinunternehmer im Sinne von § 19 Abs. 1 UStG wird keine Umsatzsteuer berechnet."


  1. On the first of the month
  2. Grab your hours from Toggl
  3. Create an invoice with those hours
  4. Sent it to your Squad Lead for approval. (Do not put the MD or on CC.
  5. Your Sqaud Lead will review your invoice and forward it himself.
  6. On the 15th you should have the money on your account.

Processing invoices

We are using a central email '' to get all invoices into our systems and incorporates'.

Those emails get forwarded to a account (to have a central log for all emails) and then forwarded to corporates invoice address.

Corporate processes all those emails and assigns them to our office assistants. They assign a cost centre and approve it.

After 1-2 days, those invoices are assigned to our MD who approves as well.

After that, another corporate employee approves the invoice as well. With that, the invoices are paid 1-5 days later.

The whole process takes 10 business days at best and sometimes up to three weeks.

Sales and Marketing

Our skills

Digital Transformation

  • App data
  • Consulting: Big data scientiesty + business casper
  • Business planing and concepting
  • Street credibility
  • ON AIR
  • Corporate background
  • Funke Exit

Product management

  • Lean development: Scope Management
  • Designen, Coden, Deployment, Hosting, Maintaining, Marketing, Monetization


  • Best and happiest coders
  • Around the clock
  • Mindset
  • Modern
  • One person in every country #glocal
  • "Cultured code"
  • Fits to distributed clients
  • Digital nomad family
  • Transparency


  • Fun with nerds
  • Techies
  • Number chruncher
  • Food & Booze
  • Work 2.0
  • First 100% distributed agency
  • Distributed
  • Lean product development
  • Digital transformation
  • Build stuff


  • Overlap of our 3 core skills.
  • Define "Stanwood Persona" after client personas


  1. "Interims CTO" Inkubator
  2. "Workbench" for agencies
  3. "Industry 4.0"
  • SME
  • Agencies


  • Website
  • Landing page
  • Blogs
  • Youtube
  • Pintrest
  • Facebook
  • Instagram
  • Linkedin/xing
  • Twitter
  • Podcasts
  • Conferences
  • Own events/workshops
  • Magazine
  • Webinars
  • Masterclasses/webinars
  • Ads
  • Newsletter
  • Case studies
  • White paper
  • Interviews
  • Influencer
  • Book
  • Merchandise
  • PR
  • Direct mail
  • Cold calls


1. Distributed

  • Meta: Work 4.0, Benefits, Lean
  • Add new processes
  • Focus on core processes
  • Culture
  • Health
  • Home stories & portraits
  • Origin story
  • Sales Strategy
  • Workation
  • Future of stanwood (3 / 5 remote)
  • Hannes/Richard/Martin private digital dungeon

2. Product management

  • MVP - Why
  • Global development process - How to get an app to the App store in 2 months
  • Data driven product development
  • Feature creep
  • A/B
  • big data
  • machine learning
  • Agile software development
  • QA (add applause)
  • Monetisation strategies
  • News apps
  • (Jean)
  • App Store Optimization
  • Product stories
  • All our products & interviews
  • Hosting & API
  • No admins
  • No server
  • Highly scalable
  • Monitoring
  • Google AI APIs
  • Client communication
  • Bots
  • Lesson learned
  • Analytics
  • Onboarding
  • IAP & Paywalls
  • Best practises
  • Why Apple will reject you
  • Apple approval strategy
  • 1.0 in Luxembourg
  • Server side feature flags
  • Design processes (re Wunderdeals)
  • Retention and conversion optimisation (CRM)
  • Push notifications & deep links
  • CRM
  • Cross platform coding (Flutter, Phone Gap, Xamarin, react)
  • Sync iOS and android development
  • Multi project management (defrag)
  • How get 5 star ratings
  • App development costs
  • Multi-tenant apps
  • Next tech: Bots, AI...

3. Digital Transformation

  • Product stories
  • Change management
  • Internal
  • Clients
  • Tools: Introduction
  • Content Marketing
  • How to make your company future proof?
  • No back-office (candies, Zohoo, Goldstein, weworks/mindspace)
  • Paperless

Marketing Operations

1. Social Media

We schedule post to instagram, facebook, twitter (MD and company accounts), linkedin (MD and company accounts) and xing (via API) via Hubspot's social media publishing tool at least 7 days in advance.

We write and plan the posts in a GDoc.


Publish one post on every channel every day.

2. Blog

We plan our blog articles in a GSheet

Legal & Contracts

Terms of use (last updated April 2019): GDoc. We always should add this as a PDF to our quotes.

Note: We offer our clients "maintenance contracts" as of Apr 2019 to "keep the app running and fix all upcoming bugs" in the extent of the usual bug fixing (20% of the total budget).

Example of maintenance contract: GDoc. Maintenance contracts are drafted by MD.


  1. PMs or MD prepare quotes for the clients (in Debitoor) and attach ToU as PDF to the quote
  2. In case PM creates the quote, it should always be approved by MD
  3. In case PM creates the quote and it requires a maintenance contract, PM should contact MD.

Note: maintenance contracts are only sent with the initial quotes for MVPs and bigger project tasks. You don't need to attach the maintenance contract to later quotes with smaller changes after the MVP was submitted (e.g. for change requests & redesigns).

You can’t perform that action at this time.