2000 Bug Software House

How to SIMPLIFY digital transformation?

2 out of 3 Small and Medium Business
shortfall Digital Transformation

The younger says "My idea will change the world. Quality doesn't matter, three months tops I will be rich."

The middle one reply "I alredy tried and failed. Now, I understand that the solution must be perfect."

The older reply "I already tried and failed. The perfect solution is too complex, and complexity skyrockets the costs."

Both the younger and the middle one ask "Now what do you do?"

It's a trade-off,
you can't have all three

A triangle showing the trade-off among User experience, Dependability and Cost efficiency

User experience is not free. It increases the complexity because you have to bend the system architecture. Complexity makes bugs happen everywhere. If you decide to fix complex bugs, you'll have an endless work called technical debt.

If you think that you need bells and whistles just like facebook.com, think how come the fair and square amazon.com is selling like water in the desert? The truth is that the user cares more for the painting than the frame.

13+ years of experience

building simple frames for SMBs to thrive

Italian School BI platform

This school had some of its reports running through Excel until the volume of data increased to the point of being a bottleneck both for efficiency and consistency.

They were inclined to build a backend-frontend architecture, to use a fancy NoSQL database, and to build everything from scratch using PHP. We recommended a unified codebase that saved 30% of what would have been spent on a custom frontend, an old but gold PostgreSQL relational database and Apache Camel as integration tool, Kogito as rule engine, and native browser capabilities such as XML, HTML, CSS and Bootstrap.

We didn't need constant rework as if something breaks every time we add a new feature. This was very strategic for the long game, as we didn't slow down over time.

US Shopify dashboards platform

This startup built a BI platform for Shopify stores to find trends in their sales data through complex analysis such as CAC/LTV and Cohort. However, the system was unstable and unreliable, preventing multiple users at the same time.

They were stuck with the idea of building a state-of-art cloud native solution with realtime capabilities and two databases, but this started to become too complex for big stores. We recommend a Linux virtual machine solution that could run the long jobs in background, developed a D-1 only solution instead of realtime that was good enough, and redesigned the PostgreSQL database to be fast enough without requiring a second database.

The platform became more stable, it could scale to more users, and the rest of the team could add new features without worrying that everything breaks all the time.

US Real Estate webscrapper

One realtor needed to ingest foreclosure data from multiple counties and to match it with his proprietary database to find good deals. This should be a one-off thing, not a system that requires constant maintenance.

His first approach was a two-people team, one junior React frontend developer and a senior for the backend in Python. We suggest getting rid of the frontend part because it was taking too long to finish and use the browser native capabilities only. Plus, all the backend was done using the Apache Camel integration tool that linked the foreclosures sources with the OCR and AI APIs and all the advanced match was done using the PostgreSQL database native capabilities.

The system was delivered on budget and there was a bug only once, that was caused by the county from where we collect the data, so we added a simple monitoring interface.

UpWork's Top Rated

100% Job Success