Building great technology starts by building a great process. This Playbook describes the process we use at Jyaasa, and includes all of the best practices, and tips and tricks we've learned over the years. We've included an example project (CookedLocal) to show you the process in action. We encourage new/potential clients and new employees to read it so they know what to expect when working with us. This is a living document that is regularly updated by our team as we learn new and better ways of doing things, so expect to see changes and improvements over time.
Most new clients are referred to us by existing clients, find us through our involvement in the tech community, or discover us on Google. After doing some basic research they will usually get in touch by completing a form on our website or by shooting us an email.
Once we receive the initial request, we’ll schedule a 30-minute call to discuss the project in more detail and answer more specific questions like:
Once we’ve confirmed that we're a good fit for your project, we will talk a little more about the Jyaasa culture and our philosophy on building technology. We will get into more detail about rates and timelines as well.
If it looks like we have a good match, we will usually sign a mutually facing N.D.A. so you know your Intellectual Property is protected, then we’ll start the first (and most important) step of the development process, the discovery phase.
Example: In 2015 HIC36 Limited , a UK based organization focused on reducing extra food in developed countries, contacted Jyaasa seeking help with building a platform designed to connect home-style chefs with fervent foodies . As a community centric service, CookedLocal helps everyday chefs plan and share their meals with fellow fresh food lovers. Riding on the coattails of the sharing economy movement, CookedLocal is re-imagining the way the UK eats.
From hobbyist cooks and experimental chefs to trained connoisseurs and street stall vendors, CookedLocal is reinventing the way communities experience food. Whether cooks want to share ‘on the house’ portions of family favorites, or sell specially cooked gourmet meals, CookedLocal supports the creations of every kitchen. As well as being authentic and affordable, CookedLocal is a deliciously effective way for everyday foodies to minimize their environmental impact.
Building custom software is inherently complex. Even seemingly simple apps have hidden layers of complexity that must be uncovered and accounted for before beginning development. The discovery phase allows our team to invest the time needed to understand your app from A to Z, and go over every required feature, user story, user type, screen view, etc., which in turn allows us to more accurately estimate time and cost.
Generally, the discovery process includes:
At the conclusion of the discovery process we'll provide you with a detailed document that describes all of the items listed above.
Example: After our first call with HIC36 Limited we had a general understanding of what they wanted to build, but we knew there was a lot of hidden complexity that we needed to uncover during discovery. Below are the findings from our discovery process, as well as wire-frames and time estimates. The app that we eventually built for HIC36 was named CookedLocal.
Great apps start with great design. You can build the most amazing app in the world, but if it's ugly and difficult to navigate, no one will want to use it, and your efforts will all have been for not. The success of your application is as important to us as it is to you, so we place a high degree of importance on getting the design right, so that you end up with an app that’s as beautiful as it is functional.
Generally, our design process includes:
Example: CookedLocal was a relatively complex application with only 24 screens to design, so the design phase was shorter than normal. In about four days of work we were able to design every view of the app, and load all of them up to InvisionApp, where we stitched everything together, and created the following interactive prototype. Although this prototype looks and feels like a fully functioning app, it’s really just a series of designs.
After the UI-UX design and major features are confirmed/approved by the client / product owner we proceed to design the architecture of the system. We basically break the whole application into smaller components/modules having single responsibility and derive relationship amount these modules in UML diagrams. We normally draw class diagrams to represent the system.
Coding is the most complex and time consuming part of building software, so we only start writing code once the discovery and design phases are complete. This ensures your budget isn’t wasted building features and functionality that will require major revision, or worse yet, have to be thrown away and completely rebuilt. It’s best to make these mistakes during the much less costly design phase, when things can be changed with just a few clicks of the mouse. As we mentioned above, we would not take on a project without a discovery process or design phase (skipping these steps pretty much ensures failure), we would rather decline the project than agree to a process that we know will fail.
Steps we follow:
Example: Once the design phase of CookedLocal was complete, we were ready to start development. We loaded all of the user stories (which were created during the discovery and design phases) into WorkBoard, and our developers got to work, knocking out story after story. Since the project was so well defined and laid out during the discovery and design phase, the development phase went very smoothly with few hiccups, and our team was able to get the first version of the app completely built in 862 development hours. Below is a screenshot of the CookedLocal project in WorkBoard, showing the user stories for the app.
Here is where we see how your app behaves in the “real world”. Even the best code will have bugs, so it's imperative that your application is put through its paces by trial users prior to launch. Beta testers often include the final users of the software, who will use a trial version of the app in much the same way they intend to use the final version.
Sometimes the beta process will be broken into a private beta, where only invited users get to test the app, and a public beta, in which anyone can log on and play around with a beta version of the software. This process will undoubtedly uncover bugs, as well as missing critical features, which will need to be addressed and/or added prior to the final launch.
Example: Once version 1 of CookedLocal was built, we were ready to start testing. We started by having everyone at Jyaasa use the app at the same time, and try their best to break every feature. This uncovered a few bugs that we were able to quickly fix. Next, we had the team at HIC36 Limited test the app in their office, without our help. Once this was complete, HIC36 Limited was ready to test the app in the field. They prepared for flyers and press release documents and released the application. Users found the app easy to use and navigate.
After months of hard work and dedication, the big day arrives and we launch your live application! Corks are popped, confetti is thrown, and backs are slapped. It wasn’t easy, but that’s the point. As John F. Kennedy said, “We choose to do these things [go to the moon], not because they are easy, but because they are hard.”
Example: After making a few small adjustments after the field testing, CookedLocal was ready to launch and be used by other foodies and awesome hidden chefs. Jyaasa built a cool website for the app, and the website was launched for public use.
Like any complex system, software requires maintenance. When you buy a new car everything (hopefully) runs perfectly. But over time, if you don’t change the oil, the engine will eventually breakdown and stop working. The same is true for software. The day will never arrive in which your application is 100% complete. A certain level of maintenance will always be needed, including:
Once users begin using your application, you’ll quickly realize that some of the features that you thought would be important aren’t really needed. And some features that you never even considered are critical and must be added ASAP. This is why it's important to budget for ongoing development upfront. Again, the best applications are always a work in progress, and are never really finished.Let’s Talk Project Management
As you’re probably figuring out, building custom software applications is a complex process that requires collaboration and input from multiple people. It’s not uncommon for a project to include half a dozen people (or more) on your side, and half dozen people (or more) on our side.
To give you an example, most of our projects will include:
Given the number of people involved, it’s easy to end up having “too many cooks in the kitchen” as the saying goes. That’s why it’s critical to have a clear project management process in place that everyone follows.
Based on our years of experience, we’ve developed the following project management process that we use on each and every job. It’s designed to increase productivity and maximize your budget, while at the same time keeping you up to date on the project. Here’s what you can expect when working on a project with us:
One point of contact. The last thing we want is everyone on your team and everyone on our team spending all their time communicating about the same things at the same time. To remedy this, it’s best to have one point of contact on your side, and one point of contact on our side, through which all communications flow.
Weekly Check-ins.You are excited about your app and can't wait for it to be finished. Every day you have to wait is torture, so everyday you want to know:
We get it. We’re excited too. But here’s the thing...these types of “checking-in” calls and emails take up a lot of time, distract the team, eat up your budget, and generally cause things to go slower, not faster.
We want to be respectful of your time and budget and we want to make sure you are in the loop on key happenings with your project. So each and every Monday we’ll have one-hour calls or video meetings with you and your team, where we will review what was completed the previous week and what’s scheduled to be completed in the coming week. This way you always know what’s going on and where the project is at, and we’re accountable to you on a weekly basis.
This also means that emails, phone calls, text messages, and chats should be avoided outside of our scheduled Monday meetings. Of course there are always critical developments that will require exceptions to this rule, but generally speaking, sticking to this plan makes the project run much smoother.
Showing you our work. Part of our weekly meeting will include showing you the work we’ve completed so far. All work is pushed to our staging servers, and we’ll review it together each Monday via video conference.
Example: Here’s a picture of the Jyaasa team meeting with HIC36 Limited for a check-in meeting.
Project Management Tools. We use a variety of project management tools to improve our speed and efficiency. A few of our favorites are:
In order to keep your project on track, it’s important for us to keep our team of designers and developers on track. To do this, we have daily, company-wide standups each morning at 9 AM. Each team member takes their turn explaining what they completed the previous day, what they plan to complete that day, and if they have any blockers (things other people need to get done before they can complete their work). If there are blockers we put together a plan to overcome them as soon as the meeting is concluded. Each team member’s daily goal is written down in our goal tracking software, and is referenced during the standup the following morning. If everything goes according to plan, all of these daily goals combined together achieve the weekly project goal that we set with you during our Monday check-in meeting. Those weekly goals add up to monthly goals, and those monthly goals add up to project milestones, which add up to shipped projects. How do you eat an elephant? One bite at a time. How do you build awesome apps? One daily goal at a time.
Lean methodology and Building Minimum Viable Products
We are big believers in lean development methodology...which put simply is an approach to building software that emphasizes building the simplest version of your application (called an MVP or Minimum Viable Product). The MVP includes only the core, critical features of your proposed application (and nothing else). This approach is the fastest and most cost effective way to get your app in the hands of users, so you can start getting feedback and learning from their behavior BEFORE you start adding features.
Sounds great right? We understand that our clients want to be as cost-conscious as possible, while getting the best possible product on the market. That’s why we work closely with our clients to ensure that the MVP vision is consistent across the team. Our experience has shown that the more lean your initial offering, the more bang for your buck you’ll get in the long run.
Why is that? Because you won’t be adding superfluous functionality that, while it may seem like a great idea initially, isn’t actually what your users want. Why spend money on code that will ultimately be scrapped. Our clients have found that it’s best to start lean and spend money only on the super-awesome functionality that their users have proven they want.
Let’s Get to Work!
Now that you understand how our development process works and our general philosophy and approach to building successful software applications, let’s schedule some time to talk about your project.