Her Story: SixPlus

We continue to share the stories of inspiring women who've founded, run, and continue to scale their companies. Today, meet Evelyne White, Founder, and CEO of SixPlus. SixPlus has been dubbed the OpenTable for groups. Their website and app helps you find and book the best private and semi-private spaces for private group dining events of six or more people.

Picture of Evelyne White

1. Tell us a little bit about yourself and your journey to founding SixPlus

I grew up with a dad who was a chef and a mom who lived to plan a good party. So whether I was in a college dorm or living in a tiny New York walk-up, working 80 hour weeks, I was always hosting. I love bringing people together around a table.

It was 2012 and I had spent 8 years working in Banking and Private Equity. I had recently been inspired by a female CEO whose company we invested in, and felt ready for my next chapter. 2012 was also the year the sharing economy really took off, led by Airbnb. I was fascinated by peer to peer marketplaces helping strangers establish trust. If Airbnb could help people sleep in strangers' homes, could I help them eat in strangers' homes?

In 2014, my Co-Founder and I launched "Airbnb for food": a marketplace for local dining experiences in people's homes. We named it BookaLokal, raised a seed round, went through 2 accelerators and had hosts in 47 countries. Ultimately, it wasn't a great business. Homes were tough to scale as a supply side. Quality was hard to control and unit economics weren't working. We could have closed up shop and returned the little capital we had left. Instead, we talked to our clients. Our only profitable events had been booked by a small segment of private groups (not traveling strangers) and we learned these clients were using BookaLokal to find private dinners for corporate events since apparently, finding a private room was really hard.

In March 2016, we launched SixPlus: a marketplace for private dining experiences in restaurants. We saw sales triple in the first month (compared to BookaLokal) and watched clients' eyes light up when they saw the product. How had no one really ever built this? And why hadn't OpenTable already cornered the market? That's for another blog post but I'm so glad they didn't!

2. How has being a woman impacted your journey?

A lot has been written about under-investment in women, at least among institutional investors, and I hope to help that statistic soon. So far we've raised from angel investors and I've had the opposite experience. Many have said the female founders they backed had the best track record and that they love investing in female founders. I'm not sure if they made 10x their money but the companies didn't fail, and they exited. Women tend to notice and agonize over "details" and "small" stuff. A) the small details add up, and B) agonizing over not losing your investors' money is a great way not to lose it!

3. What is the next step for you and SixPlus?

The next step for me is to raise an institutional round. The next step for SixPlus is to expand. We're launching new cities this year and helping companies adopt SixPlus as an enterprise-wide tool.

4. How has MongoDB changed the way you work?

MongoDB gives our product a lot of flexibility and reduces development time and effort.

5. Any advice to share for women who want to follow in your footsteps?

Find a great mentor, and a co-founder. Starting a company is easy. Building it and making it work is the hard part! You'll need all the guidance and support you can get.

Have you been enjoying this blog post series? Make sure to share it on Facebook, Twitter, LinkedIn, or Pinterest.

← Previous

JSON Schema Validation - Locking down your model the smart way

If you've read through the Building with Patterns series, you've likely seen the flexibility of MongoDB's document data model. This provides many advantages when it comes to building applications quickly as we aren't locked into a rigid data structure like we are in a legacy, tabular database. Once your schema design is determined and settled upon, it is often useful to "lock" it into place. In MongoDB, we can use JSON Schema validation to accomplish this task. Since MongoDB 3.6, we have supported schema validation based on the JSON Schemas Draft Specification . This ability to lock down the document model with a strictly designed schema means you can, for example, introduce concrete milestones in the evolution of your data model which you can test against. One potential scenario would be that after an application has gone through the development cycle and the data structure has become more rigid. At this point, defining a structure for the data may be desirable to ensure there are no unintended changes to the schema, or unexpected data being put into a specific field. For example, someone storing an image in a password field is not a desirable experience. Schema validation can be accomplished in MongoDB both during the creation of a collection and on existing documents. The validation process occurs during document updates and inserts. Therefore, when applying rules to an existing collection the rules will undergo validation only when they are modified. The syntax for implementing validation is similar in either case: New Collection db.createCollection("recipes", validator: { $jsonSchema: { <<Validation Rules>> } } ) Existing Collection db.runCommand( { collMod: "recipes", validator: { $jsonSchema: { <<Validation Rules>> } } } ) Inside the validator section of the document, we can explicitly state the fields and field types the document must have. We can define the values that a field may accept, a minimum and/or a maximum number of items a field may contain, and if we are allowed to add additional fields to the document. An example of some of these features will likely help clarify these a bit more. JSON Schema Validation For the example schema, let's think about a collection of cooking recipes. The basic information we need in each recipe will be the name, the number of servings, and a list of ingredients. We'll make those required. We'll allow for an optional _cooking_method _field should we want to be able to find all recipes for items that are sauteed, for example. We'll create a new collection and set up our validation rules. db.createCollection("recipes", { validator: { $jsonSchema: { bsonType: "object", required: ["name", "servings", "ingredients"], additionalProperties: false, properties: { _id: {}, name: { bsonType: "string", description: "'name' is required and is a string" }, servings: { bsonType: ["int", "double"], minimum: 0, description: "'servings' is required and must be an integer with a minimum of zero." }, cooking_method: { enum: [ "broil", "grill", "roast", "bake", "saute", "pan-fry", "deep-fry", "poach", "simmer", "boil", "steam", "braise", "stew" ], description: "'cooking_method' is optional but, if used, must be one of the listed options." }, ingredients: { bsonType: ["array"], minItems: 1, maxItems: 50, items: { bsonType: ["object"], required: ["quantity", "measure", "ingredient"], additionalProperties: false, description: "'ingredients' must contain the stated fields.", properties: { quantity: { bsonType: ["int", "double", "decimal"], description: "'quantity' is required and is of double or decimal type" }, measure: { enum: ["tsp", "Tbsp", "cup", "ounce", "pound", "each"], description: "'measure' is required and can only be one of the given enum values" }, ingredient: { bsonType: "string", description: "'ingredient' is required and is a string" }, format: { bsonType: "string", description: "'format' is an optional field of type string, e.g. chopped or diced" } } } } } } } }); If we look at what's been defined here, we have our required fields, name , servings , and ingredients . The additionalProperties: false rule prevents other fields from being added beyond those three fields, or fields that we explicitly state in our validation rule. We've allowed an _id field in our document which is important. If we did not specify this in the schema no document would be inserted as _id is autogenerated and no document can exist without in the database as it is our primary key. The name field has been set to a required string valued field. The servings field is required and must be an integer or double. Next here is an optional cooking_method field. If it is included in the document, only values listed are acceptable. The ingredients field has some additional complexity to the validation process. It has been defined as an array of items that each have a required quantity , measure , and ingredient . There is an optional format field as well to handle descriptions such as whole, diced, chopped, etc. The accepted data types for the various fields have been set for each ingredient during the schema validation process. Double or decimal for quantity , one of the predefined values for measure , and string values for ingredient and format . With the validation rules in place, let's try to insert some sample documents into the collection and see what would happen: Document 1 db.recipes.insertOne({ name: "Chocolate Sponge Cake Filling", servings: 4, ingredients: [ { quantity: 7, measure: "ounce", ingredient: "bittersweet chocolate", format: "chopped" }, { quantity: 2, measure: "cup", ingredient: "heavy cream" } ] }); This insert works as all of the required fields in the validation requirements are present and in the correct format. Document 2 db.recipes.insertOne({ name: "Chocolate Sponge Cake Filling", servings: 4, ingredients: [ { quantity: 7, measure: "ounce", ingredient_name: "bittersweet chocolate", format: "chopped" }, { quantity: 2, measure: "cup", ingredient: "heavy cream" } ], directions: "Boil cream and pour over chocolate. Stir until chocolate is melted." }); This insert would fail with a WriteError: Document failed validation error due to the additional directions field in the document. There are other rules that can be applied to the document as well and schema validation can be carried out on sub-documents like we've seen with ingredients but also on arrays. Additionally, schema dependencies can be set to move application logic natively into the database. Validation strictness can also be set to allow for outright rejection of the document write operation or just a warning. Conclusion JSON schema validation can be a powerful tool to maintain your data structure. This provides even greater power with the document model in MongoDB. We have the ability to rapidly try out different schema designs in an application and then, once the model has been solidified, enforce some standards. We get to take advantage of both the flexibility of the document model along with data validation. JSON Schema Validation Series Locking down your model the smart way (this post) Checking Your Arrays Dependencies you can depend on

March 26, 2019
Next →

Accelerating to T+1 - Have You Got the Speed and Agility Required to Meet the Deadline?

On May 28, 2024, the Securities and Exchange Commission (SEC) will implement a move to a T+1 settlement for standard securities trades , shortening the settlement period from 2 business days after the trade date to one business day. The change aims to address market volatility and reduce credit and settlement risk. The shortened T+1 settlement cycle can potentially decrease market risks, but most firms' current back-office operations cannot handle this change. This is due to several challenges with existing systems, including: Manual processes will be under pressure due to the shortened settlement cycle Batch data processing will not be feasible To prepare for T+1, firms should take urgent action to address these challenges: Automate manual processes to streamline them and improve operational efficiency Event-based real-time processing should replace batch processing for faster settlement In this blog, we will explore how MongoDB can be leveraged to accelerate manual process automation and replace batch processes to enable faster settlement. What is a T+1 and T+2 settlement? T+1 settlement refers to the practice of settling transactions executed before 4:30pm on the following trading day. For example, if a transaction is executed on Monday before 4:30 pm, the settlement will occur on Tuesday. This settlement process involves the transfer of securities and/or funds from the seller's account to the buyer's account. This contrasts with the T+2 settlement, where trades are settled two trading days after the trade date. According to SEC Chair Gary Gensler , “T+1 is designed to benefit investors and reduce the credit, market, and liquidity risks in securities transactions faced by market participants.” Overcoming T+1 transition challenges with MongoDB: Two unique solutions 1. The multi-cloud developer data platform accelerates manual process automation Legacy settlement systems may involve manual intervention for various tasks, including manual matching of trades, manual input of settlement instructions, allocation emails to brokers, reconciliation of trade and settlement details, and manual processing of paper-based documents. These manual processes can be time-consuming and prone to errors. MongoDB (Figure 1 below) can help accelerate developer productivity in several ways: Easy to use: MongoDB is designed to be easy to use, which can reduce the learning curve for developers who are new to the database. Flexible data model: Allows developers to store data in a way that makes sense for their application. This can help accelerate development by reducing the need for complex data transformations or ORM mapping. Scalability: MongoDB is highly scalable , which means it can handle large volumes of trade data and support high levels of concurrency. Rich query language: Allows developers to perform complex queries without writing much code. MongoDB's Apache Lucene-based search can also help screen large volumes of data against sanctions and watch lists in real-time. Figure 1: MongoDB's developer data platform Discover the developer productivity calculator . Developers spend 42% of their work week on maintenance and technical debt. How much does this cost your organization? Calculate how much you can save by working with MongoDB. 2. An operational trade store to replace slow batch processing Back-office technology teams face numerous challenges when consolidating transaction data due to the complexity of legacy batch ETL and integration jobs. Legacy databases have long been the industry standard but are not optimal for post-trade management due to limitations such as rigid schema, difficulty in horizontal scaling, and slow performance. For T+1 settlement, it is crucial to have real-time availability of consolidated positions across assets, geographies, and business lines. It is important to note that the end of the batch cycle will not meet this requirement. As a solution, MongoDB customers use an operational trade data store (ODS) to overcome these challenges for real-time data sharing. By using an ODS, financial firms can improve their operational efficiency by consolidating transaction data in real-time. This allows them to streamline their back-office operations, reduce the complexity of ETL and integration processes, and avoid the limitations of relational databases. As a result, firms can make faster, more informed decisions and gain a competitive edge in the market. Using MongoDB (Figure 2 below), trade desk data is copied into an ODS in real-time through change data capture (CDC), creating a centralized trade store that acts as a live source for downstream trade settlement and compliance systems. This enables faster settlement times, improves data quality and accuracy, and supports full transactionality. As the ODS evolves, it becomes a "system of record/golden source" for many back office and middle office applications, and powers AI/ML-based real-time fraud prevention applications and settlement risk failure systems. Figure 2: Centralized Trade Data Store (ODS) Managing trade settlement risk failure is critical in driving efficiency across the entire securities market ecosystem. Luckily, MongoDB integration capabilities (Figure 3 below) with modern AI and ML platforms enable banks to develop AI/ML models that make managing potential trade settlement fails much more efficient from a cost, time, and quality perspective. Additionally, predictive analytics allow firms to project availability and demand and optimize inventories for lending and borrowing. Figure 3: Event-driven application for real time monitoring Summary Financial institutions face significant challenges in reducing settlement duration from two business days (T+2) to one (T+1), particularly when it comes to addressing the existing back-office issues. However, it's crucial for them to achieve this goal within a year as required by the SEC. This blog highlights how MongoDB's developer data platform can help financial institutions automate manual processes and adopt a best practice approach to replace batch processes with a real-time data store repository (ODS). With the help of MongoDB's developer data platform and best practices, financial institutions can achieve operational excellence and meet the SEC's T+1 settlement deadline on May 28, 2024. In the event of T+0 settlement cycles becoming a reality, institutions with the most flexible data platform will be better equipped to adjust. Top banks in the industry are already adopting MongoDB's developer data platform to modernize their infrastructure, leading to reduced time-to-market, lower total cost of ownership, and improved developer productivity. Looking to learn more about how you can modernize or what MongoDB can do for you? Zero downtime migrations using MongoDB’s flexible schema Accelerate your digital transformation with these 5 Phases of Banking Modernization Reduce time-to-market for your customer lifecycle management applications MongoDB’s financial services hub

May 25, 2023