#replatform #celigo #builderio #algolia #vercel #nextjs #bigcommerce

Re-platforming efforts:
1. Algolia to replace in-house elastic search implementation
2. Builder.io to replace in-house built ContentAdmin CMS
3. BigCommerce to replace various aspects of orders, checkout, cart, payments
4. Vercel/next.js to replace Skeletor
5. Stripe to augment payments, replace current payment providers
6. Celigo for data moving, system integration

## Algolia
According to [[Nate Merritt]], it's pretty much a disaster.  It's "working", but one of the major features we had to keep was the ownership search where users can filter out or in products they already own.  Algolia can't handle the thousands of products that users own despite what they said some solutions would be at the beginning of discovery.

## BigCommerce
I think this is a major disaster.  Almost none of the "just works" plugins work (search, pricing, taxes).  We're going to have to reach into our APIs to do dynamic pricing, discounting, taxes, etc.

## Builder.io
I'd say builder is a big success--or will be.  ContentAdmin is clunky and builder.io is smooth and has many tools to improve content management.

## Vercel/next.js
Next.js is a great framework and I think migrating to a more modern platform is a good idea.  Vercel has great deployment tools.

However, I'm not sure it's leaps and bounds better than Skeletor--especially since it already does everything we want, we have great deployment support, etc.

The BigCommerce catalyst site is not worth the trouble. The supposed gains of it already talking to BigCommerce are undermined by the fact that BigCommerce doesn't do everything we want out of the box and we have to talk to our custom APIs anyway.

## Stripe
A great platform, I think it's a good investment.

## Celigo
I'm not sold on Celigo at all.  Every time I've tried to do something with it, it doesn't work the way I need it to and I need a ton of custom code just to get it working.  I'd rather write a custom integration where I have Git support, PR review and visibility into what code is there instead of it being hidden in non-type-safe Javascript in a Celigo flow.