Ingredients of a Service: ABCD!
AdoptionWe care about offering services that will be used.
Early thinking and planning on “How will our service be adopted by client organization?” is a big differentiator of DataChef. Unlike many heads-down engineering teams, we care about building, productizing, and persuading client staff to use our work.
To this aim, we would like to first try to understand your culture and ways of work so that we can offer our services in a way that fits what you already have. We start our mission by putting ourselves in your place and seeing it from your perspective.
By providing easy-to-understand documents and live demos, we'd like to help you understand how our efforts would fit your needs and try to answer any concerns you might have. This is rooted in our philosophy that we want our clients not to be dependent on us.
BlueprintsInstead of starting from scratch, we build on top of a blueprint.
Our product thinking and continuous investment in a growing set of recipes are one of our major differentiators in contrast to teams that build the universe from scratch every time.
Instead of repeating ourselves, we form our knowledge and experience into blueprints. This way, instead of inflicting time and expenses on you, we start with a head start and get to the bottom of your problems in no time. Some of our recipes are already shared on AWS MarketPlace. But more often than not, these blueprints need tweaks to fit your exact needs.
Custom DevelopmentModifying our blueprint to address your unique needs.
No two requirements are the same! While we use our blueprints to jump-start fast, we use our craftsmanship to implement the required customization. You might have restraints, privacy or security issues, or might need additional features. We build on top of our recipes to tailor the product for you.
In development, we follow the Shape Up method:
1. Shaping Up
We know AWS, we know data, and we understand cost and money. We don’t make empty promises with abstract words or wireframe problems in a way that is too concrete for development teams. We sit with stakeholders, trying to understand their appetites, helping them avoid rabbit holes, and making the project bounded. We technically literate the projects.
2. Betting on Features
We don’t want to develop forever, nor do we want to keep developing just for the sake of commitment. We estimate the time and expenses a project will take from our clients and compare it with the value they would receive. That is why we only bet on features that are feasible with the current infrastructures, human resources, and in the available time.
3. Shipping every Six weeks
Our mission is to deliver, and we try to do this at short intervals to make it tangible. We don’t aim for the biggest picture, but we split the problem into smaller chunks so that our clients can see the impact for themselves. We want our clients to want to work with us based on the value we bring and not to trust us blindly.
DocumentationTo make you independent, and to make ourselves redundant.
We understand the pain of failed handovers and the inability to maintain products delivered by an external party. We value documentation greatly, seeing it as an asset that makes us redundant! That’s right. We don’t plan to stay or make you dependent on us. Instead, we aim to empower you with training and extensive documents.
We see documentation as our legacy that will stay longer than any line of code. We will strive to leave a good memory in your records for years to come, and we’ll always be there for you if you have any questions.