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

An Innovative Platform enabling Sales/Marketing Professionals to be connected with their customers. Flexibly 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 an 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 salesperson 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 the phone. Unlike other contact management systems, this is highly personalized. It adheres to very tight social rules for meaningful customer interactions, so salesperson never has to worry about community feeling like they are part of a list when they get something from you. Salesperson contacts will feel like they are the priority as Bitesize manages the details to perfection. Texts come from Salesperson phone. Emails come from salesperson email account. Unlike bulk texting and autoresponders 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. The salesperson will look like a follow-up fanatic, and their prospects and customers will love them. In Bitesize system, a salesperson 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 the 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 an 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 the whole system and reduce the development time.


We identified the URL where crucial info was exposed to the public. We review the database and found crucial info stored there as well in unencrypted form. We embedded some of those with code and also started proving configuration file with application deployment. We moved registration pages of call clients into one domain as a subdomain so that domain cost can be saved and get them SSL secured with a 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 a 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 the team into 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 on longhouse and daily basis. Didn’t take a 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 the 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.