Rootstrap is a highly focused product workshop that delivers a detailed product blueprint for how to execute on your idea from start to finish. We start with a research phase where we analyze your industry, current market trends, similar successes, similar failures, and any other relevant aspects to serve as the basis for our kick off session. During the kick off, we'll do a deep dive, evaluate all findings and opportunities, and determine a product course. Depending on the current state of the product, our team will then break and begin crafting brand elements or wireframing primary user flows. We’ll review these wireframes as a team to fill in any gaps and flesh out the details, then incorporate all feedback into the flows and create an initial visual treatment. Finally, we’ll provide a feature backlog that answers two critical questions: how long and how much. We’ll work with you to groom that backlog against your budget.
I know exactly what I want and I want to jump right into development.
We respect your vision, but starting this year we’ve made Rootstrap a requirement for engaging with our development team on custom development projects. The reason is simple: it’s a critical first step in the product development cycle that’s often either overlooked or completely skipped in the traditional development model.
While many agencies talk about doing a discovery and product inception phase, all too often it gets baked into the whole engagement so the incentives aren’t aligned to create a “Minimum Viable Product,” but rather to create the maximum possible feature set – because that’s what generates the most billable hours, and that’s what’s good for the consultant. We do things differently, structuring our process to ensure that our incentive is always to get you a working MVP as quickly as possible.
This sounds interesting... How can I hear more?
Few agencies offer pre-development necessities like Rootstrap, but it’s a vital process whether you decide to engage Neon Roots for development or not. We want to empower you to make the best decisions for your company’s future – whether that means hiring another development shop, finding a technical co-founder, or building your own team. We’re happy to help you with those decisions on the first yard line after our two-week Rootstrap process.
"Neon Roots successfully developed our Latin Music by Fania Spotify app. Since the beginning of the developing process the team brought innovation and futuristics ideas to the table, which made the entire project a very easy and smooth one. They were always available to talk about ideas or even to answer simple questions that would come up along the way. The team was able to quickly develop a plan from our ideas, and develop the same one on the very tight schedule we gave them. The outcome was an amazing app that makes listening to music a much easier and better experience."
- MAYKOL SANCHEZ, VP OF DIGITAL, FANIA RECORDS
"Working with NeonRoots has been a magnificent experience. Starting with our very first sit down together, to constructing mock ups and wireframes all the way up to building our first prototype and actually seeing it work. Even more important, it was a deep pleasure working with Ben, Drew and their fantastic team of developers, designers and project managers. They are 100% committed and super responsive to demanding requests always willing to go one step further and exceed expectations. Working with NR was heads up such a worthwhile experience."
- ELENI & ANDREAS, FOUNDERS, YAGENT.COM
"Having worked with several small creative groups of developers and companies over the years I found Neon to provide the best most effective results. The difference being, having a dev with the right experience for the project and task from the start. Ramp in time is decreased because developers are not placed on projects without having gone through the proper training as well as having the full skill set needed for that specific project/product/client. For us, this increased our ability to release our product quickly while helping us save valuable dollars. Two extremely important assets in todays competitive startup climate. Thank you Neon Roots! "
- ZACHARY KAHN, FOUNDER, TALENTBOOM.COM
At Neon Roots, we are inspired by the core values declared by the Agile Manifesto (read it - it's worth your time).
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Our development methodology and framework adhere to these values. Our experience has shown us that this is the most efficient and effective approach by far, especially when you want to deploy constantly and rapidly. We prefer this lightweight methodology because it allows us to adapt and make changes easily.
This is also based on our core belief of disruptive innovation. Any business that can’t adapt – and adapt fast – will not survive. Adaptation under traditional software development approaches like Waterfall is inherently difficult, which is why we firmly believe in Agile development.
Some of the agile characteristics our clients most appreciate are transparency and the opportunities for frequent feedback. An incremental approach also lets stakeholders catalyze value-driven goals during development, and having the ability to visualize the product increments allows them to see what’s really necessary and valuable to their audience and business – something near impossible when they depend only on concepts.
Software development is inherently chaotic and always susceptible to change. At NR, we embrace these characteristics. Whether we like it or not, requirements are going to change, and we believe that this change is a necessary part of a quality and valuable product - but if improperly managed, it can also cause projects to fail. We use Scrum, a popular Agile Methodology, to handle and capitalize on the chaos inherent in the development process.
Scrum is a framework for dealing with complex processes – like software development. It’s an iterative, incremental method using self-organizing, self-managing, cross-functional teams, and it focuses on delivering the highest business value in the shortest time by allowing frequent inspections and feedback. Scrum delivers features early in the development process, helping to minimize or eliminate mismatches between client expectations and the final product output. It also gives both the delivery team and the stakeholders, through the Product Owner, a sense of predictability by avoiding major swings in the delivery. This allows both parties to manage their expectations relative to resources, schedules, and results.
For a more in-depth look at Scrum, check out Neon Roots’ “Client’s Guide To Scrum-Agile”.
Major roles in Scrum…
There are three major roles in Scrum -- the Product Owner, the Delivery Team, and the ScrumMaster. We like to refer to these roles as the “pigs.” Pigs are the ones who have stakes in the project, and they are essential to its success or failure.
From time to time, chickens may also attend certain activities of Scrum. These are people who may have something to say about the project, but they have no direct participation in Scrum activities. For a more detailed explanation of these roles, read up on the Chicken and the Pig Fable.
The Product Owner is one of the three vital roles in the Scrum framework. When you decide to partner and work with us, we require you to appoint a Product Owner. The Product Owner shouldn’t be confused with a stakeholder, even though they may also be one - a Product Owner’s job is to provide the visionary guidance for the product or the project. As a Product Owner, you are expected to adhere to the rules of Scrum, and you’ll co-manage the project with the Delivery Team.
If you aren’t familiar with the responsibilities of a Product Owner, don’t worry. As long as you’re willing to learn and internalize the core concepts of Product Ownership, we’re more than willing to help you play your part.
A small warning, though: the Product Owner role has a lot of deviation from the traditional roles of a Software Development Project Manager. You have to be very receptive of these roles and rules – while they may not make sense to you at first, they serve the best interest of the project.
If you want to learn more about the role of a Product Owner, read our short primer to get a basic understanding of your role, responsibilities, and what’s expected of you.
The Delivery Team
The Delivery Team is a cross-functional group of people who together have all the necessary skills to deliver each product increment. During Sprint Planning, the Delivery Team works with the Product Owner at the start of each Sprint to create the Sprint Backlog – a list of all the items and features to be delivered at the end of the Sprint. The team has complete autonomy on how to reach commitments made to the Product Owner, and they are responsible for conducting a demonstration of a product increment at the end of the Sprint. The Delivery Team shares project management with the Product Owner.
Our ScrumMaster is a "servant leader" who helps the rest of the Scrum team follow the process. The ScrumMaster helps the Product Owner create and maintain the Product Backlog, while also working with the Development Team to find and implement the technical practices needed to complete and deliver commitments at the end of each Sprint. The ScrumMaster removes impediments to the team’s progress, facilitates meetings and communication, and acts as a coach for the Delivery Team in executing the Scrum process. The ScrumMaster is not a Project Manager, but an aid in helping everyone follow the Scrum process.
Our Development Process
Our development process starts with project inception. Here we use Neon Roots' in-house service, Rootstrap, to establish a shared understanding by the Product Owner and the Delivery Team of the goals, requirements, target audience, and path for the product development or project implementation.
Our goal is to start with an eagle eye view of the envisioned product, then to zoom in to a level that’s more detailed and actionable. The idea is to have “just enough” information so we can initiate work at the soonest possible time - this way, we avoid analysis paralysis.
During Rootstrap, we envision and model the initial requirements, user roles, and architecture of the final product. We use this information to provide estimates to aid in planning a release. For more on this, see Agile estimation.
Tip: The goal is NOT to create a complete and detailed documentation of the project – rather, we seek to gain just enough information to get started. Remember: working software over comprehensive documentation!
Before beginning a Sprint, we do a formal kick-off to discuss items that are pertinent to the Sprint execution. This starts with a meet-and-greet between the Product Owner, the Delivery Team, and the ScrumMaster, followed by a brief review of the Sprint Roles, Activities, and Artifacts. We then set Sprint Activity schedules, and finally introduce the different development and collaboration tools.
Here’s an example of a typical Kick-off Agenda.
After the kick-off, it’s time to execute the Sprints. Our execution starts with Sprint 0 - here, our Delivery Team sets up their development environment and the different tools we use to complete and deliver a product.
If necessary, we also do spikes during Sprint 0. A spike is a story or a task aimed at answering questions rather than delivering a shippable product, and we do them when presented with a requirement or need that requires an attempt to code it to evaluate its complexity. Spikes also help us determine which path to take when there are several choices.
Caution: Spiking too often to ensure accurate estimates does more harm than good. Mike Cohn, in his book User Stories Applied, states that there’s a diminishing return on the accuracy of estimates as the amount of effort exerted on estimation increases. In other words, spending gratuitous amounts of time estimating doesn’t always lead to more accurate estimates – after a certain point, it’s better to just get started with building the product.
Setup of development environment and other tools of the trade...
• Heroku - our preferred cloud-application platform. This is where we create a staging and a production instance.
• Github - our preferred code repository and version control system.
• CI Travis - our preferred continuous integration tool for testing and building our Apps.
• Code Climate - a hosted software metric analysis tool for checking code smell.
• Rubocop - a ruby code analyzer.
• XCode - an IDE developed by Apple for software development in OS X and iOS.
• TestFlight - a free platform for distributing beta and internal release iOS and Android applications over the air.
• iOS Simulator - a development tool that allows you to prototype and test builds. We use this to simulate several iOS and several versions of the iOS operating system.
• Appium - an open source test automation framework for use with native and hybrid mobile Apps.
• RailsBestPractices - an awesome ruby gem that helps us follow the best practices on rails projects by detecting bad practices automatically.
• Reek - a code smell detector for Ruby that helps us enforce best practices while ruby coding and make the code uniform and clean across all team members.
Set up of collaboration tools...
Our framework mandates close collaboration among all the major Scrum participants - the pigs. We have a distributed team so we rely heavily on collaborative tools. Here are some of the tools we'll set up before actually starting development:
• Trello is our preferred tool in hosting our information radiator board
• Slack is our preferred way to send each product or project related notes, news, jokes, and general messages.
• Google Drive hosts our documents, but we don't have a lot of them. We value working software over comprehensive documentation.
• Bugherd - is what we use for tracking and managing bugs and feedback
Once Sprint 0 ends, we start with the first iteration. Here is a snapshot of what a typical Sprint looks like:
The very first thing our Delivery Team does is to ask the Product Owner if the Product Backlog is prioritized correctly. After that, the team selects stories to move to the Sprint Backlog - a list of items that the team commits to completing and delivering at the end of the Sprint. As soon as the Product Owner agrees to the proposed commitment, the Delivery Team evaluates each of the tasks needed to complete the stories in the Backlog.
As part of our Sprint plan execution, we do stand-ups for 15 minutes each day until it’s time for Sprint Review. During stand-ups, each team member reports to the team on three things: what they have done, what they will do next, and what (if any) impediments they have. It is a PROGRESS report, NOT a STATUS report. Again, this is a report made to the TEAM: NOT the Product Owner, not the ScrumMaster, and definitely NOT to the stakeholders.
The first purpose of this activity is to keep everyone on the team up to date with every assignment so they know how other members’ progress might affect their own. Second, stand-ups make every team member accountable for their commitments –especially if one person’s work is dependent on another’s. Third, stand-ups inform the ScrumMaster of any one member’s difficulties in completing and delivering his commitments so he can eliminate them. The Product Owner is welcome, but not required, to attend the stand-ups. If he chooses to attend, he can only listen to the Delivery Team.
After Sprint execution, we conduct a Sprint Review. Here, the team conducts a live demonstration of a product increment. The Product Owner inspects the commitments made by the team at the beginning of the Sprint, deciding which ones are accepted and considered ‘Done’ based on the acceptance criteria of the item and the pre-agreed definition of ‘Done’. If the Product Owner deems a commitment incomplete or if he has other feedback, the item is put back to the Sprint Backlog and carried over to the next Sprint.
We may also do a ‘sneak peek’ at the end of a review. After making sure the backlog is still prioritized according to the vision of the Product Owner, we check in advance the items that may be worked on for the following Sprint.
Another important activity in Scrum is Backlog Grooming or Backlog Refinement. Here, the Product Owner, Development Team, and ScrumMaster review the Product Backlog to make sure that it’s still prioritized and aligned with the vision. This provides the opportunity to remove, add, or split User Stories, re-prioritizing them if necessary. The Product Backlog can also be calibrated to align it with release plans.
After each Sprint, the team conducts a Sprint Retrospective. During the Retrospective, the Team reflects on how they executed the Sprint, identifying what went well and what can be improved. The goal here is to inspect methods and adapt what worked for the next Sprint.
Before launching the App, we go through a list of miscellaneous items that need to be completed. These mostly relate to things like creating necessary accounts, transferring ownership, and setting up the production environment – anything outside of the development process that’s still critical to a successful launch.
We always recommend an invitation-only beta release, if only for due diligence. After careful observation and addressing feedback, we can then decide to do a hard launch.
In keeping with our belief in a consistent feedback mechanism, we recommend carefully monitoring and measuring every released App. We strongly suggest using Analytics to track results, understand your audience, and continue to optimize the App based on value. See Neon Roots’ ‘The Digital Marketing Starter Guide’ for more on Analytics.
At Neon Roots, we guarantee our work. And although we follow a rigorous Test Driven Development process, we aren’t immune to Murphy’s Law – sometimes things break. When this happens, we provide the technical support and maintenance necessary to get the product running optimally again. Since each product and project is different, the type of support we provide varies on a case-by-case basis, and we limit the duration of support to compel the stakeholder to faithfully and aggressively put the product into use. In the end, this policy benefits both parties.
Code Quality and Testing
At Neon Roots, we take Test Driven Development very seriously. We use a plethora of tools and processes to ensure the quality of our code and the performance of our Apps.
We use a coding convention that every team member agrees to, and each team member needs to revisit and agree to these conventions whenever we start a new project.
• For Ruby we use this ruby style guide. In addition, we also use automated code analysis tools such as Reek, Rails Best Practices and Rubocop.
• For SCSS, here's an example of a guide we use: sass-lang.
• For Objective C we use this NYTimes Objective-C Style Guide.
We use Code Climate to check for code smell. Code Climate is a hosted software metric analysis tool that helps us control technical debts. It helps us identify hotspots and evaluate new approaches, and every incident reported is addressed before anyone can proceed and do another build.
For testing and building projects, we use Travis CI, a hosted, distributed continuous integration software. Green is definitely our favorite color:
For deploying Apps, we use Heroku as our cloud application platform. Every App is first pushed to a Staging site where it can only be accessed privately – this is where we test and review each product increment. Here, the team, the Product Owner, and other stakeholders can play around with the App without fear of contaminating the live data.
Depending on the release plan and the Product Owner’s decision, we may push a green-lighted version to the Production site. This site may be available to the public or to a select network of people invited by the Product Owner.
For sharing and publishing our code, we use a hosting service called GitHub. At the heart of GitHub is Git, a version control system that stores and manages code. This allows our developers to simultaneously work on a set of code without worrying about managing versions.
Every copy of the code – whether it be from a ‘trunk’ or a ‘branch’ – is checked-in through a ‘pull request’ anytime it is forked, worked on, or changed. In addition to our official code reviewer, we engage our entire team of developers for a voluntary code review. Only after this multi-sided review can the new copy of the code be merged to the ‘master’ -- the production ready branch. We believe that the work of one individual at Neon Roots reflects on all of us, and we are dedicated to ensuring that everyone’s work meets the bar of quality set by the team.
GitHub also has other features that we love – especially the issue tracking feature. This enables our team to collectively be on the watch over pertinent issues to address.
Languages we speak...
• For web-apps we use Ruby an open source programming language with a focus on simplicity and productivity.
• For iOS native apps we use Obejective-C and Swift.
• We also like to work with Sass as our scripting language.
• We also use Compass, an open source CSS authoring framework.
Although we try our best, we do not claim to be an all-knowing, infallible group of people: we are smart enough to seek help when we need it. When we’re confronted with a conundrum, we refer to groups and people whose philosophy and expertise are respected in the coding community. That said, we don’t just take them at their word - we also validate them to make sure they’re well suited to address the issue at hand.
This can be a very weird issue for consultants and clients to deal with. It often turns into a poker game that causes more problems than it should, with both sides trying to guess the other’s number without revealing their own.
The truth of the matter is that we need to know a client's budget. Why? Because it sets budgetary expectations on what your burn is and what your expected burn might be. If your product involves other operational costs outside of just tech, it’s important for us to know those upfront. We’re not trying to get a $20K number and then come back with a $19,999 proposal - that’s not how we work. We need to know your budget so we can adapt our services to fit the needs of your business, helping to create a better product overall.
For payment integration on your app, we recommend using Stripe. Their rates are very competitive (2.9%) and it’s easy to integrate with many things.
If your product requires physical product fulfillment, we recommend Amazon Fulfillment Services. They have white label opportunities as well.
Our fee structure is pretty simple – you pay per week for a dedicated team that sprints towards a set of goals to deliver each week. Billing weekly allows for flexibility and re-prioritization of tasks, which is essential for any product development cycle. Depending on the project size, we’ll typically get a small upfront payment and then bill each week from there.
What is weekly billing and how does it work?
"The weekly billing format was in line with our budget and business plan and allowed us to see updates quickly and know exactly what we were getting each week in terms of deliverables."
- BRIAN LAKS, CEO, SHARE YOUR SHARE
Invoicing will always come from email@example.com. Depending on the project and the terms negotiated, the due date will be listed on the invoice. We don’t believe in getting hostile or litigious when we’re not paid on time, as it kills our focus on building your project. For us, late payments simply mean we stop working.
Content Creation / Animation
Aside from the design development, we take great pride in producing all of our own original content in-house. We have access to some of the best equipment in the world, including a DaVinci coloring bay, sound studio, and of course camera equipment (we know how to work a RED, let’s put it that way). We do everything from storyboarding and script development to post-production, and we have a killer team of talented animators. To request a quote, please contact firstname.lastname@example.org.
We cover the important ones: Chrome, Firefox, and Safari. We limit Internet Explorer up to 6.
HTML5 & PhoneGap
We are big supporters of HTML5 and like to use the frameworks around it whenever possible (e.g. PhoneGap, Rubymotion). Its agility and power allow us to develop quicker and cheaper without the hassle of managing separate code bases and requiring separate development ops teams (iOS, Android, Windows, etc).
That said, we choose our technology based on the problem we’re solving. We’ve put a lot of the rumors to rest in terms of the “snappiness” or “crisp” experience hurdles on HTML5, but we spec out the requirements before selecting the technology solution. If the project requires native iOS or native Android development, we have no problem developing with those languages and tools.
We’ve trained Product Owners in everything from Scrum and Agile Methodology to learning Ruby on Rails, and we offer a variety of tailored courses to fit your goals. Depending on what you’re looking to achieve, we can help you in various ways.
We never train juniors on the client’s dime. A Jr developer at Neon Roots goes through a complete product lifecycle (end to end) before ever touching client work, and he or she is familiar with our process, tools, experience, and libraries during this training period.
"Having worked with several small creative groups of developers and companies over the years I found Neon to provide the best most effective results. The difference being, having a dev with the right experience for the project and task from the start. Ramp in time is decreased because developers are not placed on projects without having gone through the proper training as well as having the full skill set needed for that specific project/product/client. For us, this increased our ability to release our product quickly while helping us save valuable dollars. Two extremely important assets in todays competitive startup climate. Thank you Neon Roots!"
- ZACHARY KAHN, TALENTBOOM, ON JR DEVS AND PAST EXPERIENCE
Pro-Bono Non-Profit Work
We believe in giving back. Each year, we choose a handful of open-source projects, events, and initiatives that we think we can be great assets to. Check out a few of the things done these past couple years that the members of the Neon Roots team contributed to in the form of sponsorships or pro-bono work.
CRS: Country Radio Seminar
The Country Radio Seminar is an annual event that brings in some of the biggest names on the country music charts to celebrate the growth of the industry and to enhance the relationship between country radio and country music. We were honored to be a part of the 2013 CRS by creating a custom Social Media Command Center for the event.
Waza is Heroku’s one-day developer event in San Francisco, celebrating the craft and creative process of software development. The gathering features technical sessions, interactive exhibits, and keynote addresses from some of the industry’s top innovators. Neon Roots designed and developed the event registration page for Waza. By following a mobile first approach, we created a responsive web and mobile registration experience that emphasized elegance and simplicity.
Neon Roots, in collaboration with Soulcake and Nedopak Productions, created a customized Augmented Reality game for the awards event. With both 2D and 3D displays, players must save the Earth and the Geekie Awards by destroying a slew of flying robots. “Geekie Bots” is built on the iOS platform and works with or without a target marker - so even though the awards are over, there are still robots to take down!
In the fall of 2013, Neon Roots teamed with the AR storytelling and Journalism class at USC Annenberg to work on a semester-long project aimed at making the wealth of information available at the LA Public Library interactive and accessible to a new generation. Through the latest augmented reality technology, they plan to promote community and expand art appreciation through a custom iOS app.
We recommend Heroku, which is powered by AWS – they are the definitive industry leader. For staging (development server) there is no cost. For product (live) site, expect to pay $25 or more. Scaling is super easy, which is one of the big reasons we love Heroku.
Our official office hours are 8am to 6pm Pacific time, which is consistent with our Latin American office (9am UYT to 6pm UYT). Since Uruguay is only 4 hours ahead during daylight savings, the team works with our schedule. For example, stand-ups are usually around 8am PST/2pm UYT.
We have an unprecedentedly low turn-over rate for a development agency. Our retention is high because we’re always working on new projects and verticals, in new spaces, and in new mediums. That diversity, combined with just the right level of challenge, is what keeps our team motivated and excited to come into work every morning. Just ask anyone on the team how much they like working at Neon Roots!
We don’t believe in focusing constantly on work, day in and day out. PTO is a required paid day where every team member – including management – has to do something outdoors. No computers, no smartphones (airplane mode), and you have to engage in something that you love to do and are passion about. Everyone on the team casts 3 votes, with a winner and prize picked each month. This is a time for us to decompress and take our mind off of work, and we truly believe it makes us better developers.
" The thing I love about PTO is to have the opportunity to force yourself to go offline for an entire day and do the kinds of things that you love and you always postpone, like building a mini-greenhouse, learn a new hobby, or just take your beloved pet for a well deserved walk under the shiny sun, unless it is rainy (as it always happens to me :P)."
- OSCAR SINISCALCHI, NEON ROOTS DEVELOPER
Annual Retreat - Casa Los Jazmines
Everyone is welcome at our annual retreat, including clients. It’s an amazing bonding retreat to Casa Suaya, where we take full advantage of the beautiful Uruguay springtime to unplug and bond with our team for one week. We focus on high-level building strategies for our business – but we have a lot fun, too :) take a look for yourself!
This was our first retreat - Colonia, UY, 2011.
And our most recent trip to Casa Suaya in 2015. A lot can change in four years!
As a rule, we keep our development team small in order to avoid social loafing (people tend to exert less effort in larger groups), and we form teams based on each project’s requirements. Each team is cross-functional, comprised of designers, engineers, and testers that organize and manage themselves. We select team members with complementary skill sets, creating a working unit that covers all the bases necessary for the project and operates effectively to achieve its objectives.
The development team and the Product Owner (that’s you!) work together to co-manage the project. With the help of our ScrumMaster, who facilitates calls and meetings and ensures basic scrum rules are followed (we’ll explain the Scrum process later), the development team and Product Owner collaborate to achieve project goals in the best way possible.
To promote multi-sided review and allow for more open collaboration, we also have technical consultants at the development team’s disposal and we let the entire Neon Roots team review designs and code on every project. We take these extra steps to help overcome challenges as quickly as possible – we believe that the more minds set to a problem, the better the solution will be.
Your Team is Dedicated
Your team is your team. We don’t devote resources to more than one project at a time and we don’t switch them around. You’ll work with them through the entire lifecycle of your product, from initial ideation to putting on the final touches.
Open, effective communication is at the heart of everything we do. It can make or break a project, which is why we've adopted a set of practices and tools that we've found effective in keeping everyone on the same page.
Stand-ups are daily, 15 minute meetings between the ScrumMaster and the product team. As a Product Owner you’re welcome to attend, but it’s not mandatory. We’ll keep you up-to-date on discussions through Trello, and you’re always welcome to catch up on the conversation in your Slack project channel.
Consider Slack your new best friend. Your product team will use it every day to communicate, collaborate, and discuss project details in your project room. Go ahead and download the desktop client and native one for your smartphone – it’ll prove invaluable over the life of the project.
We don’t like clutter and we don’t let things fall through the cracks, and email is notorious for both. As a rule, we tend to take advantage of tools like Slack and Trello instead of relying too heavily on email.
During development, you or your appointed Product Owner will communicate constantly with the development team. In addition to daily stand-ups and Scrum meetings, you’re welcome to connect with the team through the communication channels we use.
While we value open and frequent communication, please keep in mind that unnecessary interruptions disrupt your team’s rhythm and are often counter-productive. Unless it’s urgent or initiated by the team, we highly recommend avoiding calls or meetings that aren’t scheduled ahead of time.
We cannot do impromptu meetings – if you need to meet in-person, we’ll need at least 72 hours notice. If you need to call to talk about anything outside the scope of the process and deliverables, we’ll need about 48 hours notice. This may seem unconventional, but experience has taught us that smooth, uninterrupted workflow is more effective than frantic, last-minute meetings. Feel free to refer to our Scrum-Agile Guide for more on Scrum meetings, and take some time to get acquainted with our preferred communication channels:
• Trello is our preferred tool in hosting our information radiator board
• Slack is our preferred way to send each product or project related notes, news, jokes, and general messages.
• Google Drive hosts our documents, but we don't have a lot of them. We value working software over comprehensive documentation.
• Bugherd - is what we use for tracking and managing bugs and feedback
We can’t do impromptu calls. Communication is critical in development and you have a direct line to your team every single day through tools like Google Hangouts and Slack, but unplanned calls interrupt the process. We know that as a Product Owner, you constantly feel pressured, under the gun, or influenced by advisors, lawyers, investors, and any number of other outside forces. We get that. We hear you. But trust us, we’ve based our processes on the lessons of experience – we do things this way because it works.
If you feel something is seriously wrong with the development process on your project and really need to speak with us about it, we’re more than happy to schedule a call. As product heads of the company, we don’t bill for our time, which is why we like to keep things as efficient as possible.
IT Support / Analytics / Domain Set-up
Neon Roots is more of a product development shop than an IT support center. If you want us to do something like create a Google apps account for you, we can do it – but keep in mind that it eats up time and money that could be used for development. We don’t think it’s the best use of our time, but we’ll make sure everything on the server and database side is covered.
SEO / Marketing
We have professionals certified in both Google Adwords and Analytics, and we have an in-house content team dedicated to delivering the right message through targeted SEO blogging that's both keyword rich and engaging for readers - and of course, we manage social media efforts for all our products.
If you need help with PPC management or online marketing, please let us know. After all, we're ranked #1 on Google for 'los angeles mobile app development' – we must be doing something right!
For more information on our marketing process and how we apply it to our own products, check out our published eBook, the Digital Marketing Starter's Guide.
Spec work / Pre-sell
We don't do this. Sorry!
Advisor Roles / Capacity
We’ve done this occasionally in the past. We know that you need to do whatever it takes to raise funding, and if you need to say we’re on the team, we understand that.
Vetting Internal Hires
We recognize that eventually, it’ll make the most sense for you and your company to hire internally. We’re happy to discuss an engagement where we can help you vet team members for your product and/or train them after you release an MVP with us. We have ongoing relationships with professionals across the globe, and many have acted as advisors on various funded start-ups and Venture Capital firms.
Deadline and Projected Release/Launch Dates
Estimates are always imperfect, but we do all we can to make sure our actual burns are either better or as close as possible to our estimates.
To do that, we have a detailed estimation process that involves a cross-functional team, a lot of steps, Planning Poker, and continuous revisions. We’ll spare you a detailed summary of our estimation process here, but just know that we work very hard to keep our estimates in line with our actual burns – and if you’d like to know more about the process, feel free to ask.
With that said, we ask that you please, please keep in mind that all of our estimates are based on the initial Product Backlog – the prioritized list of the project’s requirements. Any addition or alteration to that backlog as a result of feedback will alter our estimates, as will any changes in the original acceptance criteria. For more details on estimation, please read our quick Estimation Primer.
A smart Product Owner that truly believes in their idea will want to retain as much ownership as possible, but we understand that raising capital is easier said than done. While it’s rare, we do invest and subsidize a handful of deals each year with cash/equity splits – but it takes two to tango.
We know we can launch your product to market. But can you operate it and market it? Assuming we’ll be your technical partner, we want to make sure there’s a cultural fit and that our teams mesh. To ensure that, we usually only invest or subsidize costs after an initial MVP release (v1.0). This is the best way for both of us to make sure we’re the right fit for each other.
RFPs – Fixed Bid
We don’t think RFPs work when looking for a development shop, so fixed bids aren’t something that we do. RFPs only work when you’re looking for bids on a commodity, and professional services like ours are not a commodity.
Designing a product is a collaboration between the owner and the development team, and RFPs undercut communication between you and your developers. A fixed bid means a fixed feature set that eliminates the natural evolution of a product, something absolutely critical to its success. RFPs favor the cheapest bid and the most precise time frames – they do not create a partnership, and a mutually beneficial relationship is at the heart of the Neon Roots methodology. If you want our full opinion on fixed bids, check out our blog post “The BS of RFPs: Why It Won’t Help Your Search for an LA Development Shop.”
We don’t sign these because ideas are ideas. We’re pitched a tremendous number of ideas and if you feel you can’t work with us without an NDA because you’re afraid we might steal your idea, then we’re probably not the right team for you.
That said, we’re willing to have a high-level discussion on our initial call and table any specifics or novel ideas for further down the line. If we do decide to work together, we’re more than happy to put an NDA in place – this is standard procedure for all our contracts with both Rootstrap and development by Neon Roots.
We only work with receptive Product Owners. Your degree and your exit(s) don’t really matter to us - all we want is for you to be passionate about your idea and to know that it’ll be a long road to success. If you’re willing to listen and work with us, we’ll put you on the right path. Years of experience have taught us that a receptive, enterprising Product Owner who understands running lean, releasing early, and letting data dictate decisions has a much greater chance of success.
We are not a typical development agency, and your engagement with us won’t look like a typical one. It requires a level of mutual trust and respect – we intend to treat you as more than just a client and we expect you to treat us as more than just a service provider. When we work together, we are partners trying to build something great together.
One Product Owner to Rule Them All
"Developing a product requires an efficient cross-functional environment with clearly defined roles and responsibilities. Think of the process like a bicycle wheel - if one half of the wheel's spokes is comprised of key stakeholders and the other half is comprised of the development team, the only part missing is the hub that connects its spokes. This sole, central component, the wheel’s hub, gives it the structural rigidity necessary to roll forward, otherwise structural collapse would be imminent. In the development process, the product owner is the central hub that connects and supports the project’s proverbial spokes. A single product owner gives unified direction from stakeholders all while removing any doubt from the development team as to whom they should address their questions, concerns, and requests. Just as there exists no "hubless" wheel, there exists no wheel with more than one hub."
- JONATHAN & TARGETGMAT
We know how frustrating running a business can be, but please respect everyone on the team as professionals. Think of us as your product doctors – you wouldn’t yell at the surgeon who’s operating on you, right? Be kind to everyone on your product team and show them the same level of respect.
This is the main reason that Rootstrap is a requirement. It’s a chance for us to vet each other and make sure that we are the best match for developing your product.
Don’t get hung up on design
We’ve constructed our methods for data-driven design, and we don’t want you hung up on what your friends or family tell you – because the truth is, they’ll tend to agree with whatever you say. Instead of nitpicking the details, we aim to release the product, gather user feedback, and iterate. The users should always be the ones determining what to color the buttons – not you.
Don’t be afraid to release
Developing an MVP typically takes about 8-12 weeks. We value releasing quickly, gathering data, and iterating – that’s our process, and it works. Software and tech is always evolving, so don’t be afraid to show your product to the public. It may not be perfect, but it’s the only way to know what you’re doing right and what you need to change.
Putting a feature on the ‘nice to have’ list does not mean it’s off the table – we just believe in building the core feature set first (the MVP), then adding on the ‘nice to haves’ in subsequent releases. The beauty of our process is that you can re-prioritize features on a Sprint by Sprint basis.
Neon Roots is a full-service custom design and development shop specializing in responsive web and mobile solutions and custom built applications. We have three headquarters: one in Playa del Rey, CA, one in West Hollywood, CA, and one in Montevideo, Uruguay. We take on projects that inspire us, that challenge us, and that push us to innovate. We work to produce simple, beautiful, and effective solutions – but more than anything else, we create.
We are Neon Roots. This is our playbook. It will give you an idea of what we’re about, how we work, and what you’re in for.
No part of this document is set in stone, and it changes and grows as we do. It’s based on the lessons of our past experiences, and it will continue to transform with future ones.
We value simplicity, and we want to make things easy for you. If you’ve worked with developers before and you’re familiar with product development and lean startup principles, a lot of this may sound familiar to you – but we think you’ll see that we have our own unique take on things at Neon Roots. If you’re coming in blind with no tech knowledge at all, this playbook will serve as a helpful resource for you. Use it as a reference – feel free to read it, re-read it, and refer back to it whenever you need refreshers or guidance on our practices and processes.