We're a fully remote development team. We build products to grow and scale companies. Our goal is to show that it is possible for a team to live apart and deliver industry leading solutions. Teams and communities can collaborate across borders and continents and still be as efficient as the tranditional approach. Our philosophy is always that the number of hours worked has no correlation with the quality of work produced.
- Find a good financial footing: Continue to win good clients that are compatible with our ethos that will transition into social good. Build finds to ensure financial stability so that everything else can follow.
- Build a reputation for world-leading remote development: Build our expertise and reputation steeply. Become a team that is named by others as one of the best in the industry.
- Understand our impact on the industry: Identify how we make a difference and take bad as well as good experiences with us going forward.
New projects come about when the client fills out our contact form or by sending an email directly to enquiries inbox.
We have a Zapier hook, which adds the enquiry as a task inside our Pitches project inside Asana. Pitches are sorted according to their current status: iceboxed, paused, qualifying, negotiating. The whole team is added as a follower to the ongoing pitch, so they’re kept informed.
In order to progress, enough members of the team must express interest in the project for us to think we could assemble a team to work on it. If there’s no team interest, we’ll apologetically decline the lead. Where appropriate, we’ll offer a suggestion for where they might look next.
- Find out why they contacted us and would think that we would be a good fit.
- Discover their vision. Guage technical skills and level of expectation. Do they sound smart and knowlegable about their business and their goals.
- Understand the client's requirements. This is for the team to get a grasp on the work that is required for the project to succeed.
- Discover the level of commitment. Who will we be working with - who will be the product owner at the end?
- What's their budget. Get a grasp of the cost of development and timeframe. Be accepting of a degree of inexperience, knowing that the client does not exactly know the cost of development.
- Discuss a very loose timeline. Ahead of the call, we should have a good grasp of who we have available to work on the project. We'll not commit to a project deadline or set aside time for a schedules call until this has been disussed with the rest of the team.
The developers involved will report back to the team and inform with a summary of the discussion.
They should also make a preliminary recommendation to either accept or reject the lead.
We're a small team striving to deliver value to clients, particularly those who we are already working with. Writing an extensive pitch documentation and responses to RFPs taks valueable time away from our existing clients and would us require us to raise our rates.
If the client asks us to sign an NDA, we typically respond with:
Are you willing to chat without signing an NDA? We work with many clients every year. It's inevitable that we hear similar ideas.
If the NDA is important to the client, ask them to tell us enough about the business to evaulate whether there's a conflict with one of our existing or past clients. If we determine there's no conflict, and the project is a good fit, and the NDA is multual we sign it. If the NDA is not mutual we ask them to sign our NDA.
We respect confidential information at all times and won't disclose anything to our other clients.
We price and bill projects on a flat weekly rate according to the number of developers who will be required.
When we're able to gain consesnus for the project and assemble a time we'll send over and Engagement summary which sets out:
- The number of team members.
- The number of weeks being booked for the project and a start date for the first sprint.
- The broad project goal.
- The price per team member, per week.
We are a Singapore incorporation so all rates are in SGD and will have VAT added on. Invoices are automatically sent out weekly, every Wednesday, with net-14 payments terms.
International clients can pay via direct bank transfer, PayPal or Stripe.
The process will start after the contract has been signed and the client has payed for the first sprint.
We use Scrum as our main agile methodology. We belive that to operate as a mondern and efficient consultancy today you have to embrace change and constantly focus on improving products.
The workday for a developer is 8 working hours—while in rare situations it may be a little longer, this is the goal we hold ourselves to. If any developer is consistently working longer than this, that indicates that there’s a problem to be resolved.
As a team, we are highly productive and invest heavily in tools to allow us to be this way. Our philosophy is always that the number of hours worked has no correlation with the quality of work produced.
When working on a project sprint, the amount of time that will be spent on client work will be up to 7 hours (lunch break not included) in a day. The remaining hour in the day goes towards off-sprint work such as internal reviews, research, planning and internal work, all of which allows us to deliver better results when we’re on a sprint.
We work on client sprints from Monday to Friday. Since the team and clients are entirely remote, we don’t stop client work on public holidays. Although it’s rare for us to work over Christmas and New Year.
Full-time developer make their own decisions about how much holiday they’d like to take. We try to make sure that everyone takes 30 days a year.
Team members announce their holiday plans on Slack to check for scheduling issues. If there are no major problems, they then add their holiday dates into our shared Google Calendar marked with Yellow.
To minimise holiday disruptions, we ask that developer try and plan holidays to avoid departing mid sprint. Since sprints run Wednesday to Tuesday, this means that departing on Wednesdays, and returning on Tuesdays is easiest for everyone.
Working remotely is one of the best-known elements of our culture. It has been the way we’ve worked since the very beginning, and we intend to stick to it. For us, it’s a way to allow our team the flexibility to build great lives around their work, which in turn, helps them to enjoy their jobs more and to be more productive.
We are very flexible about where team members choose to live and work. The biggest requirement is that regardless of where you choose to be based, you must make sure you have an internet connection that’s good enough to handle video calls with clients and the rest of the team.
Team members get login details for our OpenVPN servers. VPN usage is compulsory whenever you’re working on public wifi.
Where we feel it would help us to do a better job on a project, we may bring in collaborators to help us. These contractors will be booked on the same, weekly basis, and will become full-time members of the project during the booking.
Confidentiality of project and client information is important, so each of these contractors will sign a standard Independent Contractor Agreement. This will be sent out from HelloSign, and sets out our standard confidentiality terms, along with other conditions for working on the project.
We’ll also send a single booking document, which will set out the dates we’re booking to work together during.
Collaborators will be added to the project management tools (such as Trello) that they need in order to carry out their roles.
We use Slack for internal chatter, including marketing discussion, and general chat between developers.
For all internal communication that requires a task to be completed use Trello.
As for the tools we use for each project—that really depends on the project. We’ll often use Pivotal Tracker to run projects, but if the client has a defined workflow and we need to integrate into it, we’ll switch from anything from GitHub issues, to apps such as JIRA.
Internal calls usually happen over Skype—we feel the audio quality is better than Google Hangouts. There are always video calls.
Since some of our developers are located in the same cities we meet up for social food and drinks. This usually happens on the last Thursday of every month. Before each meetup we all join in on a Hangout talk about how the month went and potential topics for the evening.
While we understand the need of everyone in the team to be able to hit deep focus, we also believe that teams build better products together than any one person can by themselves. To accomplish this, we make sure that regular team calls are a built in part of every workday.
We use Screenhero lots for internal pairing sessions, and also frequently pair on Google Docs.
Each month, during the first week of the month, every developer has a 1:1 call (or an in-person chat, if they’re in the same city) with Ole. In short, it’s a chance to have a chat about how the month went, and what else our company can be doing to help you grow, and make life better for you.
One of our most important cultural values is that we will never settle. This means we work really hard to help our developers grow.
We believe in using this to set individual goals or long term goals which eventually will broaden our knowlengde base and increase the team's strength. These goals should be fairly ambitious, if you're over or under your goal by the time of evaluation we 'll use this again to set the next goal or pivot. OKRs are not synonymous with employee evaluations. OKRs are registered in Trello with a description of your goal and a due date.
Also described in this article Set goals with OKRs.
We look for talented, cross-functional developer. Since we do a lot of work with early-stage startups, versatility and a wide range of skills, is important. As is the ability to work really closely with other members of the team, remotely. Location is not a problem.
A new developer would usually get in touch through our job application form or by sending an email to our jobs inbox.
This will get piped through Zapier into Asana where everybody can see and ready for the team to make comments and reply.
If we've never worked together before the developer will join the first available sprint to see how it goes.
If the developer is at a novice/intermediate level we'll evalute further training and the developer will go through our standard traning process.
We hold fast to the philosophy that great results on complex challenges come from building a great team around the problem. We don’t believe that any of our developer should be working solo.
So we build small, cross-functional teams for each project. This means that depending on the project needs, we’ll typically have 2 developers working on each client sprint.
We also don’t feel that great work comes when our attention is split between multiple projects. A consistent project team, which doesn’t change on a regular basis, is the best way to build great relationships with our clients and to make sure that team is productive and understands the project deeply. So team members will stay on the same project for the whole sprint, working full workweeks on that project, rather than working on multiple projects at once.
Team schedules are shown in Google Calendar, and teams are responsible for managing their own schedules and also requesting help from other team members, as needed. Where possible, we will aim to avoid having sprints run back-to-back. Downtime in between sprints is for internal work, including marketing, blogging, and building team tools.
To make sure we start the project in full speed we'll send over some research we've done and some tasks prepped for the client.
- The product's business model.
- User feedback on the current product, if it exsists.
- The company and product history so far.
- Competitors.
- The key project objectives.
Getting solid answers on these points will have a huge impact on the quality of work during the first week. Understanding the client's vision and direction absolutly nessesarly for the project to go foward in a fast pace.
During the first day we start out by using the information received by the client up front. We'll spend a few hours looking at the information at hand and understanding the client's vision. We'll contact the client directly if we find any issue with the provided information or we feel something is missing.
We work together to set out priorities for the sprint and break down weekly milestones.
We use Trello for collaboration with the client. This allows us to get a good grip of the amount of work and prioritize the tasks accordningly.
We see the importance of rapid-prototyping and transparency. Our first goal is for the client to see the result of development fairly quickly and that the work is transparent. The client should be able to follow up on ongoing work so there will be no major changes, surprises or regressions in the development.
Before we start the project we decide on the technology best suited for the project.
From our experience it has shown that the Ruby on Rails framework can bring a product to the market more quickly than the alternatives. As a product of a wast community it supports excellent rapid development capabilities, with good standards when it comes to applicaiton performance and security.
With a large community behind us we large modular applicaitons with less code ownership as modules used in the applicaiton will be maintained by the community.
The Rails and agile community has every strong bonds. This means Test-driven developemt, Object-oriented design and less repeated code.
To bootstrap a project we usually use the following gems/modules.
- Ruby on Rails - Web Application Framework.
- Devise - Flexible authentication solution for Rails with Warden
- CanCanCan - Authorization Gem for Ruby on Rails.
- Datagrid - Gem to create tables grids with sortable columns and filters.
- Simple Form - Forms made easy for Rails! It's tied to a simple DSL, with no opinion on markup.
- AASM - State machines for Ruby classes.
- Searchkick - Intelligent search made easy with Rails and Elasticsearch.
- Title - i18n your
<title> - Phony Rails - This Gem adds useful methods to your Rails app to validate, display and save phone numbers.
- Money Rails - Integration of RubyMoney - Money with Rails.
Our preferred choice is currently Twitter Bootstrap, will wil be used in the majority of our project with overrides where nessesary.
When the client requires a more advanced frontend and the User Experence becomes a crucial part of the application we resort to ReactJS. ReactJS is a pure Javascript framework for build user interfaces currently developed by Facebook. React came in with a huge hype and provided everything that was promised.
For the client this means rapidly developed, beautiful and intuitive user interfaces. There are numerous examples out there, but most commonly known on Facebook and the Facebook apps on iOS and Android.
As users become more demanding they will naturally require applications that are more interactive and require real-time interactions with their fellow users.
The Phoenix Framework has been spesifically designed to support next-generation web applications. Applying the convetions of Ruby on Rails framework, developers can rapidly build applications that are highly interactive while serving millions of users.
At the end of the development we'll end up with a repository containing:
- Full-source of the projects.
- Graphics and design used in on the site and in the project.