VAT is only levied if it doesn't get exported within a certain amount of time (6 months from the scheduled delivery date).
I knew someone who tooled around Europe for a month before dropping it off to be shipped to her without having VAT incurred (though it was a couple decades ago).
I'm building an ERP to encapsulate the whole "customer" journey. I'm building it to be a business operating system of sorts with a goal of creating clear line-of-sight visibility for all activities along journey's like lead-gen to churn (but in a variety of settings).
The goal is make it easier for organizations to work with external parties that affect finances (customers, investors, vendors, etc.).
The idea was born out of personal frustration that I've faced in a variety of leadership roles in organizations, that lead to wasted effort, slower decision making, bad decisions made with equally unhygienic data.
I've solved this successfully in the past form of internal tools and a data governance layer (data warehouse with much more authority).
My preferred language to build apps is Ruby, and I'm still more likely to pickup RoR as a backend. But I can't see if winning in the AI generation.
I never recommend it with LLMs, because there is a definite context window and attention problem with a lot of languages, but Type-safety + being pre-trained on strong typing, makes any issues with context sizes moot. The latest generation of AI dev tools, are getting really good at solving problems using the type errors that it creates.
Also a lot of Rails niceties can be achieved in languages like Typescript with patterns such as decorators, which do an amazing job DRYing things up and reducing those contexts.
This is a very good start, I don't think it'll replace a lot of the custom code/comboboxes that are seen in react-land without search (unless I missed it).
I for one am very excited about where things are going.
I know we're getting fewer "traditional" junior devs, but I'm seeing more and more designers and product managers contributing, at a frequency which was much harder pre-GPT.
In my roles as a head of product/eng, I've always encouraged non-technical team members to either learn coding or data to get better results, but always had limited success, as folks were scared of it (a) being hard, (b) taking too much time to get proficient.
But that's changing now, and fast - and these junior devs are becoming proficient much faster and leading to much business and customer outcomes.
I'm seeing more realistic goals, sprints, etc. I'm seeing fewer front/backend bottleneck, and lastly I'm seeing fewer pixel moving requests going to senior engineers.
As other have mentioned juniors were often unable to code prior to LLMs, and what helped make them better was code reviews, bugs and general mentorship. Those tools to make them better are still available to us.
It's an intriguing take, but as others have pointed out, the truth will be somewhere in the middle. I don't believe that AI will replace the entire SaaS interface. And I also don't think it will need as many services and APIs of yester-years.
This writeup seems to be authored by a senior designer at Salesforce and I can see the motivation from the their perspective. Their challenges are different than what a new SaaS product will encounter.
Like all the incumbents of their time they are a core-ish database that depended on a plethora of point solutions from vendors and partners to fill in the gaps their product left in constructing workflows. If they don't take an approach like being discussed here – or in the linked OpenAI/Softbank video – they will risk alienating their vendors/partners or worse see them becoming competitors in their own right.
Disclaimer – I'm biased too, I'm building one of the upstarts that aims to compete with Salesforce.
Pretty cool. Lots more info on reddit threads.