D-BUG is the tool behind Daedal consultancy which uses industry insight to design a new capability solution for large CPG companies. They seleted Looming Tech for the development and implementation of the entire end-to-end platform build process. We started off with an ideation session and then built an MVP which was tested with some partner brands. We then adopted a ‘bit by bit’ approach to building the platform, starting off with the key architecture and then adding on the first modules. We then tested the modules and successfully launched with our client partners in October 2021.  Technologies involved: - UX Design with Adobe XD- Front end with ReactJS and Redux- Responsive and mobile first design- Backend with NodeJS, Serverless, AWS, Postgres- Auth0 integration- Custom reporting with HighCharts

Our customer: StreetChefs decided it is time for them to develop their own food delivery platform. They selected Looming Tech as their tech vendor because we have done similar (and even more complex) projects and were happy with the design, quality of work and overall understanding of the business.The platform we delivered consists of:- Mobile App (android + iOS) for food ordering- Mobile App (android) for delivery people- Tablet App (android) for restaurants- Website for food ordering- Backend System + Database- Machine Learning model to predict orders and particular meals for a given time and day, helping with shifts planning and ingredients managment.- Integration with payments system (myPos)- Integration with invoicing system (Barsy)- Administration Panel for business managers Tech stack we used:React Native, HTML, CSS, TypeScript, NodeJS, Serverless, AWS, Python

I have my MVP, now what?      We constantly talk to people, potential clients, CTOs and tech entrepreneurs and we hear the same story again and again. “I have my product already built by those guys    from X, they did what I’ve asked them to but the quality was poor and I am just not  sure how this will scale with bringing in more users. I even had hired that security  consultant and he found plenty of issues of great concern”. Now that could have probably been just a small POC, sometimes a MVP, on other  occasions a full blown first release of their product idea. But it happens and          This is how it all began with Grasp.HR      It is not atypical for us as a company to take over systems built by someone else and make them world class, addressing the scalability issues, the security flaws and  improving the general quality of the software. What we did for Grasp at the very beginning is that we carefully analysed what was  already in place (requirements, product at hand and source code) and came up with  recommendations on how this could be improved, how much would it cost and of  course when would it be available.  It is always a balance of course between what business wants right now and  addressing that technical debt - but it is a dialog and a decision optimal for the  customer. In our case Grasp.HR had this big client waiting for the product to be ready so they  can start using it.     The team we put together      For less than 2 weeks after they have selected us as a product development partner we had our first team members to start: Senior PO, Java Engineer and Automation QA. That was part of our plan since we had to start with product road map definition (hence the PO), fixing the urgent security issues (Java engineer) and covering the app with UI/Integration automation tests (the QA). Ultimate team size after month 2:  1. Agile PM / Product Owner 2. Tech Lead 3. Java Engineer 4. Front end engineer 5. Devops 6. Automation QA   More on: https://www.looming.tech/post/grasp-hr