Multi-platform Grocery Ordering and Barcode App
Budget: $750 – $1,500 USD
GROCERY STORE ORDERING APP REQUIREMENTS
We want a phone app (I suppose it could be web-based, as long as it works on a smartphone and does what we want; it must work on an Android phone at a minimum) that we can give to our customers (grocery stores out in the Alaskan bush) so that they can order groceries for their store (generally, by going down each aisle and scanning products and tags for products that they want to order, inputting the number of cases they want to order after scanning the item) and then send the orders to us when they're all done. The app needs to hold a database of our products (so information about the product, like name and price, can be displayed when the person scans an item), and this database needs to be able to be updated by us remotely, so we can add/remove products and change prices.
We need this app developed and tested as quickly as possible. We require the source code of the finished app.
1) The app needs to be super simple to use. At a minimum, it needs the following functionality from the user’s point of view:
a. The ability to create an order
b. The ability to add items to an order
c. The ability to review/edit an order
d. The ability to submit an order
e. The ability to scan barcodes to look up items
f. The ability to search for products by name or browse products by category
g. The ability to take a picture of an item and enter some information about it, if the user wants to order an item that we do not currently sell (i.e. is not in our product information database; see (2) below)
h. The app should save old orders, so that the customer and review their order history (plus, I'd like the app to display when an item was lasted ordered and how many units were ordered when the item is selected/scanned; for instance, if I scan an item, I want to know that I last order X units of this product on such-and-such a date).
2) The app needs to be able to work with an external database containing product information. The nature of this database can be whatever is convenient for the developer (especially if the developer already has a pre-existing solution that uses Excel, MySQL, etc), as long as we can easily update the information, such as adding/removing products and changing prices, remotely. The database will contain the following information, at a minimum:
a. UPC
b. Our vendor code for the item
c. Product description
d. Pack count
e. Weight
f. Price
g. Product category
3) Whenever an item is scanned/selected, the above information is to be displayed (at a minimum, (b)-(f) and historical information, such as the date and order quantity of the last time the user ordered this item [which can be obtained from looking through their past orders in the app], must be displayed). The product information page will contain an “Add to Order” button. An initial list of items for the product database will be supplied to the developer in Excel format, which the developer can convert to their preferred format. The app must check for updated product information databases, which it will download during the app startup phase (I've left this open-ended if the developer has a preferred method, like checking for one in a specific email, downloading from Dropbox, etc).
4) When submitting orders, the order submission should contain the following, at a minimum:
a. A customer identification number (so we can determine which customer created the order)
b. A list containing our vendor code followed by the number of cases the customer wants of that product
5) The order submission should contain just the items ordered, not the entire product database (which are expected to be quite large) with a bunch of zero entries and a handful of nonzero entries. This is important, because our customers have limited bandwidth available to them.
a. Orders can be sent to us via email, uploaded to Dropbox, integrate directly with Acumatica (which is the software we use in house) or another method that is convenient to the developer (especially if the developer already has a pre-existing solution). If using email, keep in mind that we want the pictures the customer took of new items they want us to order for them as well (see 1(g) above). If there are a lot, the size of sending them might exceed the acceptable limit of an email size.
6) The app should have a way for the customer to contact us (our contact information and being able to send a message to us within the app or whatever)
7) The app should contain our company name and logo
8) We are under tight time constraints. We’d like a fully working and tested version before the end of January. We are willing to work with a developer that already has a pre-existing solution that they can modify to meet our minimum requirements.
I'm attaching pictures of another similar app to what I am describing.
We want a phone app (I suppose it could be web-based, as long as it works on a smartphone and does what we want; it must work on an Android phone at a minimum) that we can give to our customers (grocery stores out in the Alaskan bush) so that they can order groceries for their store (generally, by going down each aisle and scanning products and tags for products that they want to order, inputting the number of cases they want to order after scanning the item) and then send the orders to us when they're all done. The app needs to hold a database of our products (so information about the product, like name and price, can be displayed when the person scans an item), and this database needs to be able to be updated by us remotely, so we can add/remove products and change prices.
We need this app developed and tested as quickly as possible. We require the source code of the finished app.
1) The app needs to be super simple to use. At a minimum, it needs the following functionality from the user’s point of view:
a. The ability to create an order
b. The ability to add items to an order
c. The ability to review/edit an order
d. The ability to submit an order
e. The ability to scan barcodes to look up items
f. The ability to search for products by name or browse products by category
g. The ability to take a picture of an item and enter some information about it, if the user wants to order an item that we do not currently sell (i.e. is not in our product information database; see (2) below)
h. The app should save old orders, so that the customer and review their order history (plus, I'd like the app to display when an item was lasted ordered and how many units were ordered when the item is selected/scanned; for instance, if I scan an item, I want to know that I last order X units of this product on such-and-such a date).
2) The app needs to be able to work with an external database containing product information. The nature of this database can be whatever is convenient for the developer (especially if the developer already has a pre-existing solution that uses Excel, MySQL, etc), as long as we can easily update the information, such as adding/removing products and changing prices, remotely. The database will contain the following information, at a minimum:
a. UPC
b. Our vendor code for the item
c. Product description
d. Pack count
e. Weight
f. Price
g. Product category
3) Whenever an item is scanned/selected, the above information is to be displayed (at a minimum, (b)-(f) and historical information, such as the date and order quantity of the last time the user ordered this item [which can be obtained from looking through their past orders in the app], must be displayed). The product information page will contain an “Add to Order” button. An initial list of items for the product database will be supplied to the developer in Excel format, which the developer can convert to their preferred format. The app must check for updated product information databases, which it will download during the app startup phase (I've left this open-ended if the developer has a preferred method, like checking for one in a specific email, downloading from Dropbox, etc).
4) When submitting orders, the order submission should contain the following, at a minimum:
a. A customer identification number (so we can determine which customer created the order)
b. A list containing our vendor code followed by the number of cases the customer wants of that product
5) The order submission should contain just the items ordered, not the entire product database (which are expected to be quite large) with a bunch of zero entries and a handful of nonzero entries. This is important, because our customers have limited bandwidth available to them.
a. Orders can be sent to us via email, uploaded to Dropbox, integrate directly with Acumatica (which is the software we use in house) or another method that is convenient to the developer (especially if the developer already has a pre-existing solution). If using email, keep in mind that we want the pictures the customer took of new items they want us to order for them as well (see 1(g) above). If there are a lot, the size of sending them might exceed the acceptable limit of an email size.
6) The app should have a way for the customer to contact us (our contact information and being able to send a message to us within the app or whatever)
7) The app should contain our company name and logo
8) We are under tight time constraints. We’d like a fully working and tested version before the end of January. We are willing to work with a developer that already has a pre-existing solution that they can modify to meet our minimum requirements.
I'm attaching pictures of another similar app to what I am describing.