The 'Multi Level' Product Sales & Marketing Support Engine .

An Innovative Platform enabling Sales/Marketing Professionals to be connected with their customers. Flexiblly designed to support all industry verticals with - Just a bit of customization


Request for Proposal

Business Introduction

Bitesize system based on Software as a Service (SAAS) model where we host the web and mobile applications as a service provider and made them available over the network. Bitesize is a of product, using which Multi Level Marketing Companies can create and design the process in advance through which sale representative of the company keep his contacts in motion whether they are prospects, customers or even business associates. Using system a sales person can be perfect at follow-up, follow-through, and staying in touch. It ties into pre-designed contact series events that organize, manage and execute emails, texts, and scripted phone calls designed to keep sale person prospects and customers moving.


All they will have to do is to follow the reminders sent to phone. Unlike other contact management systems, this is highly personalized. It adheres to very tight social rules for meaningful customer interactions, so sales person never have to worry about community feeling like they are part of a list when they get something from you. Sales person contacts will feel like they are priority as Bitesize manages the details to perfection. Texts come from Sales person phone. Emails come from sales person email account. Unlike bulk texting and auto responders that only go one direction, Contacts can respond to the texts and emails sales person send them. Events become sequenced, referenced, and even build on each other. Sales person will look like a follow-up fanatic, and their prospects and customers will love them. In Bitesize system a sales person can also track goals and tasks for sales.

Challenges & Solutions

To set the process for development, testing and going live, we require all information scattered around in emails, docs, shared drives into one place. Below are the things in order we did to have process setup in place.

  1. Moved to JIRA, logged all existing production bugs in JIRA and had them prioritized.
  2. Separate for Development, in development environment QA performs testing on Bugs and User Stories level.
  3. Separate environment called Release where QA perform Regression Testing.
  4. Separate environment called Staging which is exact replica to live where QA perform Smoke testing before going live.
  5. Breaking requirement into smaller chunks like Epic and then those chunks into User Stories.
  6. Each story assigned to dev and QA at the same time so that they can work them together.
  7. Created a Road Map for next 6 months with going live in every 15 days including planned stories and bugs and backlog if any.

We took and complete overview if system and advice them new third party tools which can improve the efficiency of whole system and reduce the development time.


We identified the URL where crucial info was exposed to public. We review the database and found crucial info stored there as well in unencrypted form. We embedded some to those with code and also started proving configuration file with application deployment. We moved registration pages of call clients into one domain as a sub domain so that domain cost can be saved and get them SSL secured with wildcard certificate. We also established an architecture which is loosely coupled, robust and scalable.


After doing complete analysis we decided to move server hosting from Go daddy to AWS. We also thought of this as an opportunity to clean up existing loose ends. We did it very nicely, clean and moved data to new server per user at the time when they upload new app version on their devices. We didn’t choose to move all data once because downtime was not affordable as Users were paying 10$ and 15$ a month for using the app.

We divided team in 2 parts, one for giving production support where they resolve high priority existing bugs on production and another working on new features. We had worked for long house and daily basis. Didn’t took break even on weekends and at times worked for 2 days nonstop and achieved highly stable system on few months.
We handled this programmatically, added version identifier key in API, through which we can differentiate from which version of app we are getting request and separate set of logic (code) will get executed depending on from which app version the API being hit.

We added a parameter on API’s, so that in backend we can figure out which version of app user is using. Based on the app version we process and pass the data to front end accordingly.

We move from PayPal to PayPal Standard Pro and in Authorize.net we move from ARB (Automated Recurring Billing) to CIM (Customer Recurring Profile) , difference here is that we get ProfileID(Authorize.net) and BillingAgreementID(PayPal) rather than a subscription ID, and we can tell them when to generate a charge rather than having it done automatically/Recurring. This gives us a lot more control, as our requirement was subscriptions with varying time-periods and charges.