@Brandon Burgason thanks for sharing, checked out the project. Here is a mixed bag of questions, thoughts, suggestions:
Likes
WoWonder looks cool, and the original docs are well documented.
I've bought and deployed several apps from Envato/codecanyon in the past with pretty good success but you should know that there will always be changes, fixes, additions needed - hence the need for a free lance dev as mentioned by Tony as well. In many ways not a bad price to pay for buying the code at < $50. WoWonder also has 9.2K sales with a 4.84 star rating and over 1K likes. most recent update on on Dec 9th (always good to know the project is being maintained)
Digital Ocean is a fantastic platform for hosting and it seems they actually own or self-built CloudWays
Biggest risk: Typescript/JS is by far the most preferred defi-integration langs i.e. web3js is a lib used for onchain interaction (in apps) of onchain smart contracts. It's going to become hard and expensive to use public libraries only sticking to PHP. We. can find other devs but the point is we then "have to find other devs"
[2:52 AM]
Dislikes/risks
I'm not the biggest fan of PHP - is a shrinking, not a growing language.
Coupled to the above, PHP developers therefore are harder to come by than Javascript developers for example
There are quite a few things that need to be done after purchasing WoWonder codebase: deployment of test and live env, setting up up the QA env (git/dog ocean pipes), frontend changes, backend configs and then physically creating apps with all the Auth providers & PSPs to get and update the API keys accordingly (FB, Twitter, Strip, RazorPay, etc..) It's a bunch of work and usually a FE dev cannot handle all the devops and vice versa.
We probably do not want to outsource devops. It's the heart beart of "everything" - if a freelancer leaves then entire project is at risk. FE, BE, design - sure, not devops.
[2:52 AM]
Things that are unclear
Tony eludes to a horizontally scalable (pod/server-segregated) cloud infrastructure as "decentralization". Let's just be clear that that's referring to the ability for multiple organizational-level instances to be run (nothing is decentralized as all data is still housed within same auth body) which leads to the next part
I think @Brandon Burgason what's really critical is a single view (but more detailed/succinct) of the building blocks of what we're building? Why? How do they interact? etc. I've drawn a quick example diagram below of what I mean:
[2:53 AM]
I think the architecture is the number one most important the agree on else we could get WoWonder setup in a few hours but then we realize, perhaps with more microservcies that Digital Ocean is not the best cloud ops platform anymore, etc..
[2:55 AM]
And it may be prudent to find other (non-PHP) projects that are similar in feature-suite to WeWonder that exist and evaluate them
[2:58 AM]
From my XP - devops can really sink an incredible amount of time and we don't yet know, what the expected metrics or OKRs are?
how many users should we support at what server load?
is scaling standalone servers for entities part of the launch scope, if not, how to we build an architecture that allows for horizonal scaling later?
if we constrain data by entity offchain how do we shard the same data onchain? (else it's pointless)?
mikey___brink
— 12/11/2023 3:01 AM
Basically, this project needs a clear plan, with goals, milestones, a budget, an architecture (high level + dev-ready), resource identification based on the agreed architecture and an incremental growth (feature building) plan else we're going to herd cats
Sorry for the barrage, but just some more thoughts:
It'll be good to understand the go-to market strategy as well -coupled to- the tech. So for e.g. we clone WoWonder as a social engagement platform > for purposes? xyz
Then we need a mobile app for OneAccord which is the interface for all the funding, donating, DAO, etc.. + potentially a B2B2C layer (it makes sense to have that in OneAccord but not in WeWonder) or do you want WeWonder to become OneAccord?
If we intend WeWonder to by synonmous w/ OneAccord then we need to write a new mobile-ready version with Play & App Store accounts and subscription payments setup w/ Google/Apply Pay? Or build an entirely onchain payments rail but massive barrier for adoption if crypto from the start?
I'll stop here but I feel so far from understanding the product vision but I don't yet have answers to these inital questions ..
Tony’s Response
His questions are business questions for One Accord.
PHP isn't going anywhere
Global ecosystem of devs. Will be harder to find US based devs as it's not where the money is at.
The recommendations was so you can begin building a community and generate revenue and growth.
If you're going to go hard into a Dev cycle and begin planning out your at scale architecture, whole different conversation and one that needs to be geared to your talent/labor/capital resources.
Without capital, you need to crawl before you walk, and walk before you run.
Wowonder gives you a place where consumers can interact in a familiar feeling ecosystem.
Those consumers generate revenue.
You could run Wowonder to 10k+ people while building out an entirely new platform to your architecture specifications and simply port the data to the new code base.
This is a business decision.
How important is it that you provide a community platform to
1) generate revenue
Or
2) get investment
You want to build out your own community platform you're gonna need a minimum of $250k to get the ALPHA right, you're gonna need another $1M to get to BETA
That's just development costs. Not marketing, growth, or anything else.
One Accord is a big mission.
It's gonna cost you a minimum of $5M to get to GL 1.0 if you do it right.
Email from Mikey to Andreas (Dev who can spin this up)
Please meet Brandon. Brandon has purchased a web app called
Obtain and plug in APi keys for 3rd party insrtegrations (all built and function within WeWonder) e.g. Stripe, etc.
Modify the frontend appropriately: logo, colours, show/hide elements as required by Brandon, etc.
So as you can see it's very little code writing, and more devops + bash (config/install commands) and configuration/setup of API keys and other environmental variables (mostly).
Brandon is meeting w/ the team next Tuesday but wanted to set the stage and see if there is a fit for you to be involved in this first phase.
I'll let Brandon elaborate more as needed.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (