This is Lightmatter's playbook. We use this document to guide our process, strategy, and values as we grow as a company. Our playbook is a living document: as our company expands, our process will change.
If you'd like to join our team, email firstname.lastname@example.org.
If you invest in startups and are interested in learning more about partnering with Lightmatter, please read our VC Partnership Program.
Below are Lightmatter's core values. We hold each other to these standards, and encourage our clients and partners to do so too.
We believe in being kind to each other. But kindness is not just being pleasant. We think Andrew Bosworth best phrases what being kind actually means when he writes "Being kind isn’t the same as being nice. It isn’t about superficial praise. It doesn’t mean dulling your opinions. And it shouldn’t diminish the passion with which you present them. Being kind is fundamentally about taking responsibility for your impact on the people around you. It requires you be mindful of their feelings and considerate of the way your presence affects them." - Andrew Bosworth
We believe in clear and frequent communication, with effort made to predigest information before interacting with each other - seek to understand before being understood. Being transparent implies honest communication, whether good or bad news is discussed.
We believe in creating an environment where creative resourcefulness is the standard - where open mindedness is practiced daily and people are encouraged to express their opinions while being prepared to have them challenged and challenge those of others.
We believe in being humble when teaching, in understanding your mistakes and those of others, and when interacting with others outside of Lightmatter. Being humble implies an understanding of your own strengths and weaknesses, and that no single team member makes or breaks the team.
We like working with smart, entrepreneurial, and open-minded people and companies. You could be a very small organization, in fact, just yourself, or you could be a Fortune 500 company. What matters is how passionately you care about building and executing on your project.
We are a product development firm, technical consultancy, and innovation lab. We enjoy building things, and we make money through consulting.
The majority of our clients hire us to either
Build a consumer facing digital product for web, mobile, or both.
Build an internal tool or B2B product used to improve business operations or sales.
Act as an "in office" innovation partner to leverage technology through both design and development as needed.
We also perform architectural evaluations of existing codebases to improve performance and offer Strategy, UX, and UI consulting independent of our development work.
We do not take on equity projects regularly.
We charge for our work by the week rather than by the hour, and our clients pre-purchase weekly or bi-weekly sprints in advance.
We partner with other consultancies, Venture Capital firms, and established startups and businesses to drive our sales. For these partners, we provide architectural evaluations of their code, help interview potential candidates, and act as a technical sounding board. In exchange, we seek referrals and introductions for other partnerships. If you're interested in becoming an official partner, email email@example.com.
At Lightmatter, we guide our clients and their applications through four phases of development. We've tested this methodology across countless projects, and have found that it consistently leads to a higher quality product.
At the start of every project, our team kicks off with our version of a design sprint where we facilitate structured workshops that help us all understand why we're building something together and who we're building it for. During these sessions, we also work with clients to pinpoint the problem they’re trying to solve and determine the functionality required to achieve the business goals and user objective identified during this process.
As part of our design sprints, we set aside time to do user research and analysis. This typically involves surveys, user interviews and persona development. We also put together a project canvas which helps us all get on the same page and answer potentially tough questions quickly.
User-centered design can help improve customers’ experience of a website, product, or app. Once we have a clear understanding users’ needs and preferences, we then begin sketching out wireframes. From sketches we then like to move into a design tool for further refinement and then the browser. Our goal is to get into the browser (or whatever medium the product lives in) as soon as possible.
Once UX is complete, we add color and life to the application. In this phase, we apply our clients' established branding to the overall look and feel of the product and add specific interaction annotations to make sure that development of front end components runs smoothly.
We check the following with each set of designs we create:
In this phase, our team creates a detailed Styleguide that displays an application’s full UI framework in one view. This Styleguide is a living blueprint that is referenced when programming work begins for the application. Styleguides create brand consistency across browsers and devices, and make continued development more productive. The Styleguides we create enable developers to quickly address issues that may arise during development.
A great list of examples can be found here of companies documenting their branding with Styleguides.
After we've created a Styleguide we begin writing code. We dedicate a full week to review the application's Models and assumptions. It's critical that our clients join us for meetings this week so that there is full clarity moving forward. During this phase, we review and decide the structure for multiple parts of the application, such as the URL's, Models, front end components, and forms (if applicable) of the application. During this week, we can better predict a project's timeline and original estimate.
At the end of this phase, we gather any UX / UI revisions and create a list of data to be used in the next phase of Milestone and Ticket writing.
In this phase, we write user stories as tickets in Pivotal Tracker, and organize these stories into larger groups called milestones. Each milestone, which contains a series of tickets related to a certain feature, is considered a Sprint. A good example of this is authentication. Assume that as a user, one should be able to login, logout, reset their password, change their password, and update their username. These are 5 examples of user stories, which make up 1 milestone called Authentication.
Once we've created our user stories and milestones in Pivotal, we're ready to begin development. We hold our first Sprint meeting, usually on a Tuesday, where we review the tickets in our first milestone. Each Sprint is two weeks in length. Under some circumstances, a Sprint may be 1 week if we're building a smaller feature.
Sprints meetings have a specific agenda, which can found here. Sticking to this agenda helps keep the meeting and overall project on time.
Throughout each Sprint, we make continuous releases to our development and staging environments, and dedicate time to QA each set of features we build with our clients before each Sprint. In our QA meeting, we review the features from the previous Sprint. We take note of improvements to make, any bugs we discover, and possible new features we'd like to add.
With most of our applications, we begin by writing and defining the application's models. We hold a UMCF meeting for every project where we map out, before any code is written, the application's:
From this meeting, we can better assess a project's timeline and original estimate. We also have an understanding of where dynamic data touches the site, what information a user can and can not submit, as well as the front end components that we'd like to use as the visual building blocks of the site.
Software is best compared to a garden. Gardens need attention: lots of watering, occasional pruning and weeding, and a vigilant caretaker to keep away bugs and pests. However, the best gardeners know that weeds will always grow back, so finding and tending to them becomes a habit. Just as a garden, bugs and glitches occur in software. They may be the result of faulty code that we wrote, or they may also occur because of third party code or other applications with which we interact. They're inevitable, part of the software development process, and something that we expect along the journey. When bugs happen, remember that they're part of the product development process, and by finding them we make the application sturdier and more robust.
As we near the end of our milestones, we make sure that in the final few weeks of development we diligently track and record any bugs happening and incorporate any final feedback or requests. We write any final tests in this phase so that our application has good coverage, and require that our client's have a small handful of user's test the site. It's a low stress period where we make tweaks and any final adjustments before launching.
After testing the application with users and modifying the final product, we're ready for launch. Occasionally, we'll work with clients who prefer to keep their project in private mode so they can either raise or recruit their users slowly.
We meet daily at 11 to discuss what we each did yesterday, what we are doing today, and if we are blocked on anything. We keep this meeting to under 15 minutes, and leave knowing what we need to accomplish for that particular day.
We hold a Sprint planning session every two weeks. We usually hold these on Tuesday when our Sprint begins. In a Sprint Planning meeting, we look at the upcoming work in Pivotal Tracker for the Sprint and delegate the work, answer questions, list unknowns, and estimate the time needed to complete the work. During this time we also look at the previous Sprint and ask "what went well" and "where can we improve?"
We encourage our clients to come to the Sprint Planning meetings to participate in the software development process, and our best one's begin to act as their own Project Managers.
If for some reason we're having trouble working with our client during the Sprint Planning meeting, we'll ask that we keep the Sprint to developers only, and will summarize the upcoming work for that Sprint with our client after.
We feel it's important to continuously demonstrate progress as we build our applications. We like to hold Demos with our clients routinely, usually every 2 to 3 sprints. In Demos, features are not expected to be complete or bug free. They're simply a chance to allow our clients to interact with their product and course correct the timeline and budget as needed. Demos are great for discovering bugs because we begin to see how new users interact with the application.
During the project concord, we meet as a team each week to sync on the week's Sprints and perform initial QA. We use this time to code review and merge outstanding branches, deploy to our staging environments, and review tickets in Pivotal
For each project at Lightmatter, we have our team carry out the following positions. Each role is responsible for the following criteria:
The single most important action a client can take to ensure the success of their product is to launch early and launch fast. We advise agaisnt delaying launch for new features or browser specific bugs.
We work Monday through Thursday on client projects, and use Friday to invest in Lightmatter. If someone on our team is sick that week or there is a holiday, we often use Friday to catch up for that week on our client work. On Fridays, we like to:
Write code and contribute to open source projects we maintain
Invest in our project templates and internal tools
Write blog posts
Work on upcoming speaking engagements and conferences
Interview potential hires by pairing with them for the day
In any software project, there are inherently going to be bugs. Bugs may be the result of faulty code that we wrote, or they may also occur because of third party code or other applications we interact with. The number of bugs experienced can be mitigated by writing tests. For all of our applications, we write tests and keep coverage records on a per file basis to ensure a high code quality.
When beginning work with us as a developer or client, it's important to learn our toolset and workflow. We use a variety of tools throughout our software development process.
Pivotal - we use Pivotal Tracker to write features, track bugs, and use as a dashboard for overall project progress.
Harvest - we use Harvest to track our time and send invoices.
Github - we use Github to hold our repositories and perform code reviews. We use a technique called GitFlow to keep organized branches and deploys. Credit to Vincent Driessen for a concise infographic.
Slack - we use Slack as our team's central communication hub. Many of our team mebers are remote, and Slack helps us stay organized.
Hellosign - we use Hellosign to sign and send our legal documents. We dislike actual paperwork.
CircleCI - we use CircleCI for continuous integration.
Sentry - we use Sentry for error monitoring.
Heroku and AWS - depending on the scope of the application, we'll use either Heroku, AWS, or some combination of the two. If using AWS, we're comfortable applying tools within Amazon's ecosystem like Elastic Beanstalk, CloudFront, ElastiCache, Route 53 and more.
When writing code at Lightmatter, we try to stick to an Agile Methodology. Not all projects fit this requirement, so it's important we remain flexible. Our general process is as follows for feature development, bug fixes, and releases:
A Sprint meeting is held, where the development team meets to discuss tickets in Pivotal Tracker for that current sprint. Questions are raised and a discussion ensues, and tickets are assigned and estimated by the developer completing that ticket. At the end of the Sprint, every developer should have a clear focus for what work there is to complete.
After the Sprint, we begin work. A developer will start a ticket, and click 'start' on that ticket.
After starting a ticket, the developer should create a feature branch using the GitFlow methodology for that ticket. More feature branches are better than too few. Ideally, there should be a feature branch for each ticket, unless making design tweaks.
Once the ticket is complete and ready for a code review, the developer will click finish, and push up their code for review. A team member or lead engineer will review the code, comment, and either accept the work or request changes be made. If a change is needed, the lead engineer will assign a 'needs changes' tag to that branch in Github.
Once the code has been corrected or is ready from the start, the lead engineer gives the green light by assigning a 'ready to merge' label to that feature branch. It is the engineer's responsibility who wrote the code to merge the branch into the develop branch in Github.
Once the branch has been merged into develop, our continuous integration tools will deploy that version to a development environment to be previewed and tested. When the feature branch merged into the develop branch and deployed to our develop environment, the developer should click "Finished" on the ticket in Pivotal.
By the end of the Sprint, we'll observe all of the tickets completed and features built, and make a deploy to a staging environment. This is usually where we allow our clients to observe and test the app, as well as where a project manager will perform QA. When the develop branch is deployed to staging, the project manager will mark the tickets as 'delivered."
The PM will perform QA by either accepting or rejecting a ticket. If rejected, a reason should be given as well as steps to reproduce, such as a screenshot and browser information.