In my humble opinion and experience, this is a bad idea. If you don't have cash and can't raise it either, then you should be willing to give equity. Otherwise, your proposal may end up self-selecting a poor quality developer. The reason being is you're asking the dev to take on too much risk in return for very little reward, and the offer/demand curve is against you (there's lots of other entrepreneurs willing to pay cash and/or give equity for a good developer). I run a small software development firm (see www.chimi.co), we build mobile apps (among many other things), and we'd not accept this. We have, however, in very few occasions (e.g.: known entrepreneur we've worked with in the past, and upon satisfactory due diligence from our side, etc) exchanged a discount on services in exchange for (vested) equity.

Hello there,

Stripe has a daily subscription plan option that you can easily integrate with (hint: our innovation platform at https://www.chimi.co supports it out-of-the-box). While you can't tell it at which time of the day to process the payments, they would typically fall in (similar to your comment, but should actually work) around 24 hour multiples of the subscription creation time. I haven't tested this myself but, in addition, if you (programmatically) delay the subscription to be created within your time window, then the following daily recurring payments should also fall within that same time window.

Hope this helps!
Seb

Full Disclosure: I'm the founder of ChimiChurri (see http://chimi.co). We build the kind of membership website/application you are looking to build by leveraging a proprietary product building platform and a professional services team. I'll attempt to keep my answer as honest / unbiased as possible.

The quick answer is you can likely build your membership website with either. But, WP is, IMHO, the wrong tool for the job. I have built WP sites and coded WP plugins before and, from a software engineering perspective, you'll likely very quickly end up in what I'd typically describe as "plugin mess". Meaning you'd probably end up with a duct-taped ball of WP + custom theme + several (different) third-party plugins + custom code + third party services that will be extremely hard to maintain and continue to iterate and build upon. So, while doable, you'll sacrifice quality and accumulate "technical debt", to say the least.

As per Ruby on Rails, it is a very solid MVC framework I have used to build many products and applications throughout my career, including marketplace and market-network type applications like the one you are describing. But, with RoR alone you'd indeed have to build lots of custom functionality to get to MVP or v1, and that will take money and/or time.

With Chimi (our product building platform), you can get the best of all worlds: a solid, robust Ruby on Rails application that has lots of the features you are looking for available out-of-the-box, without sacrificing quality, flexibility, or ownership, and with a relatively small budget and fast execution and implementation time.

With Churri (our professional services) you also get access to top-quality engineers and developers that can build custom features and integrations unique to your needs.

Let me know if you'd like to setup a time to chat - I'd love to give you a demo and see if we'd be a good fit for your needs.

Generally speaking, I think building a web app for your marketplace concept first can be a great option to launch, then move on to develop a mobile app later on whenever it makes the most sense. Building a web app (vs. a native mobile app) will usually require less time, effort, and money, and if you build it right (responsive, etc.), it can potentially work pretty well across desktop, mobile, and tablet.

That said, there're many other considerations to think about. Here're a couple quick examples:
- target audience & their environment: if you're targeting millennials, mobile may be a lot more important than if your application is typically used by professionals during working hours (in which case web first is a definitive winner in my book).
- hardware needs: do you need to leverage camera / mic / video / sound / accelerometer / GPS a lot? if so, you may be better off building a native mobile app.
- validate: keep in mind you'll have to validate your concept at many different levels (problem, solution, marketing, channels, UVP, cost structure, price & revenue structure, etc). Building a web app can help with lots of this, but it wouldn't be the first move I'd recommend: if you haven't yet validated at least some of your assumptions around problem, solution, and customer segments, I'd suggest you consider validating your idea further before starting to build. And, as a side effect and while you do that, it may also become clearer whether a web app can work or if a mobile app is a must-have.

Just a quick couple thoughts to get you going. I work on this specific topic a lot with my prospects and clients (I build responsive web apps - including marketplaces -, but not mobile apps). I have advised different clients to go with mobile-first and web-first approaches on different occasions, and also advised a couple of them to go back and validate their ideas further before building anything. Let me know if you'd like to setup a call to go over some more specifics to your situation.

Depending on how many simultaneous users you want the application to be able to serve at any given time (peak), and how much processing your application does when uploading and downloading files (as well as other typically used operations), your hosting specification requirements may vary.

But, to offer some basic guidance, you could probably get started with about 3 Virtual Machines (2 for load balancing serving the web application itself, and one running the database). I'd get them with around 4GB ram and 2 CPU cores each. These run at around $40/month each on Digital Ocean. You could also use AWS, SoftLayer, Heroku, and others, each with their own pros and cons. For example, if you use AWS you could (depending on which database you're using) leverage RDS for your database which could simplify your scaling and operations. I'd suggest you store the uploaded files on S3, Object Storage, or similar service (as opposite to serving it from the file system which makes it harder to scale).

Hope this helps as a quick guidance. As you can see there's lots of options and details to consider. If you'd like to setup a call, I can certainly help you dig deeper into the different options and which ones would work best for your specific needs.