There's even a Scraper as a Service: page.rest/ (discovered some time ago by @pugson – thanks mate! 🙌)

For me personally it varies and is based on the specific type of an idea.
Sometimes I just hack up a teaser/landing page outlining the main concepts and start to collect emails and/or Facebook Page/Instagram follows. The rate of signups allows me to decide if I should abandon it altogether, introduce changes to my initial idea & teaser site or forget about the outside world and start to code. For the main part I like to give myself around 2-4 weeks for a soft research (core concept, competition, monetisation) and gathering results before jumping straight to coding.

We're using Drift's free plan at #nowelizator (in combination with their iOS and Android apps for push notifications on the go) and it works like a charm 👌

Love the idea, reminds me of tosdr.org/

Have you thought about assigning scores to each reviewed policy? I personally would like to get a short summary in the beginning (instead of scrolling through the whole page and doing assessment by myself).

As for the visual design aspect:
• Try to narrow the content instead of letting it flow from side to side. There are studies showing that the optimal line width contains around 3 times the whole alphabet (78-80 letters per line) - narrow the column/scale font size accordingly. Remember that the longer the line, the harder it is to maintain flow of jumping to the beginning of the next line (because our brain forgets if the beginning of this particular line was already read).
• Center aligned text is hard do skim/read
• Section titled "Data shared with Facebook" is long, but each line is fairly short. Have you thought about containing each line within a card and then aligning them into multiple columns? Maybe even group them by category, or differentiate them visually (by color?)

Could you elaborate a bit more on the state of the idea, eg.:
1. It's a raw idea that needs to be validated (from nothing to being sure that there's something to it or people don't need it)?
2. It's an MVP struggling to get traction and you're thinking about ditching it?

It depends on such aspects as:
* how often are these images accessed?
* how fast do you need them served?
* how big they are (file size wise)?
* how much are you willing to invest in modifying your current infrastructure?

If we're talking about a bunch of small files that are served constantly on each request (like avatars), I'd put them alongside my backend (eg. inside of a DigitalOcean Droplet) and introduce caching;
If you're thinking about larger files that are rarely downloaded/displayed (eg. renders of PDF files), I'd put them into an object storage (like DigitalOcean's Spaces/Volume) to reduce costs;

Recently I've heard very good things about cloudinary.com – a service that stores and serves your images (acting like a CDN with built in image scaling/processing abilities). Have a listen to syntax.fm/show/033/large-file…

Hi @bearson, thank you for your time and insight 🙌

My initial thought was to ask for money right before data processing step. This should make users comfortable with using their cards (by proving via overall quality and implemented flow that this app is a real deal). From psychological standpoint, by this time users should be quite involved with this app (by uploading and preparing their data) and be more inclined to pay for the service. Additionally I was thinking about allowing users to process a small batch 1-2 records to give them a taste of the output before making the purchase. Of course the pricing will be known from the get go (even before signing up).

That being said, asking for the money upfront doesn't feel right – I'm afraid that it would discourage potential customers from getting to know the service 🤔