How Monograph is Moving Upmarket with OneSchema
Learn how OneSchema provided Monograph with the ease of adoption, flexibility, and cost-effectiveness they were looking for in a data importer tool.
July 31, 2024
.png){kind=spacer}
Architects and engineering firms use Monograph to track and analyze their financial and operational performance across projects. As Monograph expanded its services to larger customers, robust data migrations became a top priority. Monograph implemented manual methods, but they weren’t scalable. Since each customer file was not standardized, each data file had different required columns / mapping validations. Unimported data migrations piled up, and the team knew they needed a better long-term solution. Being able to ingest customer data quickly and efficiently was a key component of Monograph’s onboarding experience. After evaluating different solutions for a data importer tool, they arrived at the conclusion that with each customer having 10-15 different data sources, building a generic data importer tool in-house wasn’t feasible.
During Monograph’s evaluation process, Devin Burke, lead engineer heading the onboarding and data migrations project, highlighted the most important factors:
Monograph knew that building an in-house importer didn't make sense for their business. It wasn't just a matter of cost-savings. Devin had worked at a data migrations company previously and knew firsthand how complicated data migrations could be. “Even if OneSchema was priced 10x what it was today, it would be worth it - I still wouldn’t want to build my own.”
He knew that as an application grows over time and new features are added, each one of those new features could potentially break the data migration flow. A senior engineer on the team was leading these migrations for large, new customers and much of the time was spent in Excel data cleaning, which is now automatically done with OneSchema. As Devin puts it, "You don't need senior engineers working in Excel to validate data and work on data transformations, but sometimes you have to. "
Monograph was drawn to the ease of adoption and flexibility of Oneschema, allowing them to implement a frontend immediately and use OneSchema out of the box: "The biggest thing was OneSchema allowed us to write our own validation hooks in our system, in our language. Other platforms don't allow you to do that." This level of flexibility allowed Monograph to focus on building out their product while OneSchema handled the template header matching and data validation layer.
OneSchema was more user-friendly for their developers and more plug-and-play compared to other options. During their initial presentations, OneSchema Devin noted that OneSchema was faster to implement compared to other solutions and had predefined validations that they still use to this day, which meant less code for them to write. In contrast, other data importer platforms didn't have any custom validations to use out of the box or would have required them to learn a new language.
Another important requirement for Monograph was that the tool needed to be clean and user-friendly for their customer experience team. Devin explained that OneSchema's UI for fixing errors was more intuitive to use compared to other options: “When you move towards a more defined solution like OneSchema, it then allows you to have more well-tested migrations. Now that we have built it out, we have tests and more confidence around data migrations.” Monograph's complex data required a tool that could scale and handle importing from multiple SaaS platforms.
When it came down to the cost-benefit analysis, Monograph found that using a third-party option like OneSchema had strong ROI. Devin explained that with an in-house solution, there wouldn't be additional new features unless they built it themselves. In contrast, with OneSchema, they saved upfront on development costs and have been pleased with monthly new feature launches. With increasing migrations on the horizon, Monograph knew that building a generic importer wasn’t an option. Additionally, with 10-15 different data sources, OneSchema could handle standardization across all templates, and the Monograph team was able to create a single template to map across the board.
Monograph found that OneSchema provided them with the ease of adoption, flexibility, and cost-effectiveness they were looking for in a data importer tool. Devin concludes, "If we were a company with only one competitor, building an in-house solution might make sense, but we saw all different kinds of companies coming through. By using OneSchema, Monograph is able to focus on building the product and scaling with our customers.”
{{blog-content-cta}}
Architects and engineering firms use Monograph to track and analyze their financial and operational performance across projects. As Monograph expanded its services to larger customers, robust data migrations became a top priority. Monograph implemented manual methods, but they weren’t scalable. Since each customer file was not standardized, each data file had different required columns / mapping validations. Unimported data migrations piled up, and the team knew they needed a better long-term solution. Being able to ingest customer data quickly and efficiently was a key component of Monograph’s onboarding experience. After evaluating different solutions for a data importer tool, they arrived at the conclusion that with each customer having 10-15 different data sources, building a generic data importer tool in-house wasn’t feasible.
During Monograph’s evaluation process, Devin Burke, lead engineer heading the onboarding and data migrations project, highlighted the most important factors:
Monograph knew that building an in-house importer didn't make sense for their business. It wasn't just a matter of cost-savings. Devin had worked at a data migrations company previously and knew firsthand how complicated data migrations could be. “Even if OneSchema was priced 10x what it was today, it would be worth it - I still wouldn’t want to build my own.”
He knew that as an application grows over time and new features are added, each one of those new features could potentially break the data migration flow. A senior engineer on the team was leading these migrations for large, new customers and much of the time was spent in Excel data cleaning, which is now automatically done with OneSchema. As Devin puts it, "You don't need senior engineers working in Excel to validate data and work on data transformations, but sometimes you have to. "
Monograph was drawn to the ease of adoption and flexibility of Oneschema, allowing them to implement a frontend immediately and use OneSchema out of the box: "The biggest thing was OneSchema allowed us to write our own validation hooks in our system, in our language. Other platforms don't allow you to do that." This level of flexibility allowed Monograph to focus on building out their product while OneSchema handled the template header matching and data validation layer.
OneSchema was more user-friendly for their developers and more plug-and-play compared to other options. During their initial presentations, OneSchema Devin noted that OneSchema was faster to implement compared to other solutions and had predefined validations that they still use to this day, which meant less code for them to write. In contrast, other data importer platforms didn't have any custom validations to use out of the box or would have required them to learn a new language.
Another important requirement for Monograph was that the tool needed to be clean and user-friendly for their customer experience team. Devin explained that OneSchema's UI for fixing errors was more intuitive to use compared to other options: “When you move towards a more defined solution like OneSchema, it then allows you to have more well-tested migrations. Now that we have built it out, we have tests and more confidence around data migrations.” Monograph's complex data required a tool that could scale and handle importing from multiple SaaS platforms.
When it came down to the cost-benefit analysis, Monograph found that using a third-party option like OneSchema had strong ROI. Devin explained that with an in-house solution, there wouldn't be additional new features unless they built it themselves. In contrast, with OneSchema, they saved upfront on development costs and have been pleased with monthly new feature launches. With increasing migrations on the horizon, Monograph knew that building a generic importer wasn’t an option. Additionally, with 10-15 different data sources, OneSchema could handle standardization across all templates, and the Monograph team was able to create a single template to map across the board.
Monograph found that OneSchema provided them with the ease of adoption, flexibility, and cost-effectiveness they were looking for in a data importer tool. Devin concludes, "If we were a company with only one competitor, building an in-house solution might make sense, but we saw all different kinds of companies coming through. By using OneSchema, Monograph is able to focus on building the product and scaling with our customers.”
{{blog-content-cta}}
