https://www.Kandoop.com, a productivity platform (better Evernote + Trello + WordPress-ish for custom feeds). It does a bunch of good stuff.
AWS, PostgreSQL + Redis + S3, BE is 100% Python-based Lambda functions, FE is browser-native WebComponents (no frameworks), mobile app is the same FE code wrapped with Cordova, on Google Play and Apple App Store.
Serverless functions are my #1 tip to reduce low-value maintenance time for solo devs / small teams.
My new product, Kandoop (at https://www.Kandoop.com and on the app stores). It uses a cards-in-boards model, and is intended to be full life-cycle from an individual with an idea, to team task/project management, and curated publishing (custom "news feeds" that are intended to be a clean view for executive stakeholders, partners or customers). One of the key features is that "lists" of cards (boards contain lists, lists contain cards) can be attached to more than one board, so everyone can create the optimized view for their role. Example of when that's helpful include manager <-> direct-reports task views, where the manager wants everyone's list in a single view, but can't share the whole board with everyone due to private info. So the lists are shared with the relevant team member, who can put that list in their own personal to-do board, while the manager can create a board with all of their direct reports' lists.
My app CardBoard (https://www.cardboard.team/) is no-framework vanilla js. This is a large-ish codebase with a lot of functionality, and the same code is wrapped with apache cordova for both iOS and Android apps. In 2022, browser-native WebComponents (addresses encapsulation, code organization, and re-use) with no frameworks is a hill I'd die on.
The difference between an agency/consultancy (selling services) and a product company is enormous. There are other advocates here for product, but since the $100k you mentioned is probably for a services engagement (you don't have a product yet), I'll share a warning about that model for a startup. When your business sells services, you essentially become a broker between people who need a type of work (your customers), and people who can do a type of work (your employees and sub-contractors). The health of the business, then, is tightly dependent on the relationship between the demand from your customers, and the availability and cost of the people with the right skills to execute the work. Assuming you're already in a good place to gauge the customer demand, my warning is about staffing to execute the work. It's easy to imagine that legions of the experts you've worked with previously will be inspired to join you, but you'd be surprised how untrue that can be (or possible but more expensive, due to the risks of a smaller company). Yes, it's possible to create a great, sustainable services business, but it's important to be aware of the challenges you can face with staffing, retention, keeping customers happy, and doing it all within a commercially viable margin.
Agreed on the hit-the-ground-running problem. Related to your final point, assuming that you're not coming into a situation well-known by all parties to be a shit show, I think there needs to be a Minimum Patience Period (probably relative to the size/complexity of the project, window given to get up to speed, etc). For example, if the product is working well, the release cadence is acceptable, the defect rate is low, etc, I think the prior devs have earned a reasonable benefit-of-the-doubt MPP that a new dev should accommodate for learning the existing approach and rationales. I've seen a senior dev completely change tooling and build process for a "fine" app at the end of their second week. All good ideas in the right time, but...
Off the tools topic, but IMO the most important consideration: the mindset should be entirely about understanding the existing approach, conventions and philosophy, vs a critical assessment leading to "this needs to be modernized". Particularly on small-medium codebases with smaller teams, I've seen projects be fundamentally damaged by new, well-meaning devs who bypass most of the hard-slog of really understanding the existing how/why, and instead try to jump to the more comfortable space of using tooling or approaches they're more familiar with. There is certainly a place for that, but depending on the project, that might be 3 to 6 months later. Programmers need to appreciate the power and consequences for management and non-programming team members (product) when a new dev brings a condemning assessment of an existing codebase after one or two weeks.
Great question. WC doesn’t provide any architectural structure beyond code encapsulation for your UI widgets. But this alone gets you per-feature sandboxing, even more strictly if you use the shadowdom to get runtime isolation as well (I typically don’t, but it’s a good fit for many solutions). This allows you to move ahead pretty quickly, knowing you can tear out and replace these elements easily if you got it wrong or the needs change, without core changes to the app. Yes, you still need foundational services like data access & caching, personalization, etc, which sit outside of WC, but the “best way” for those things is typically very tied to what you’re trying to build. So for those, I typically just start with a functional “sketch” of each service with a lot of code separation, and let the architecture emerge through iterations of refactoring as I start to understand what I need. The biggest refactor problems tend to have to do with precedence of rules and order of code execution, with the biggest issues at initial load as arrival scenarios get more complicated. But no framework is going to solve those problems optimally for your app, and more likely, the frameworks create more obstacles to doing it well. And then there’s always the problem that your devs need to be really knowledgeable in the framework to not apply it badly.
I’ve been working on an SPA built with no frameworks, a lot of WebComponents, and almost zero 3rd party code, and it’s fantastic. Package managers and frameworks have a lot of holdover momentum from an era when they were far more necessary, and I think a lot of teams and individuals have unacknowledged PTSD that prevents them from stripping out these legacy comfort & safety nets. Plus, it’s likely also a comfort for managers to believe a team is working within some sort of opinionated 3rd party-supplied guardrails.
One yet-to-be-mentioned element here is the dynamic of developer preference and resistance. As systems bifurcate into relatively cookie-cutter "lego"-like technical components (the Wixification of the entire stack via cloud, frameworks and no-code), vs the heavy-lift coding to make the framework "legos" themselves, a lot of the fun development is going to go away (development with a direct end-user feedback loop and the reward of solving some real-world problem). This dynamic also eliminates a good entry point for developers (basic apps and web sites), which allow them to build the knowledge to create and love those more sophisticated re-useable legos, because they understand the true pain of solving those original problems without them. I predict a big, negative impact on the future population of developers arriving to software from "creative" entry points, like design, marketing, or finance, because the bridge will be gone. What will be left are only formally educated engineers.
AWS, PostgreSQL + Redis + S3, BE is 100% Python-based Lambda functions, FE is browser-native WebComponents (no frameworks), mobile app is the same FE code wrapped with Cordova, on Google Play and Apple App Store.
Serverless functions are my #1 tip to reduce low-value maintenance time for solo devs / small teams.