Database design for small startup
There are really several different things in play here:


Recovery to the current state if the DB server is lost. Synchronous replication is your only option here, but it comes with some risks - if the replica goes down or fails the master will stall, and if there's much latency then performance will suffer due to the need for the replica to confirm before commits are accepted. Setting synchronous_commit = off for transactions that aren't crucial can help.
Recovery to a recent state if the DB server is lost. Asynchronous replication and is what you want here. It doesn't guarantee to be up to date to the latest committed transaction, but has less performance impact.
Recovery to some previous point in time to cope with accidental deletions, corruption, etc. Your two tools here are dumps and PITR (wal archiving), with different advantages. PITR lets you recover to a finer-grained point in time ("what was in my customer table just before Bob dropped it?"), but doesn't protect as effectively against corruption of database storage and can require more disk space. PgBarman helps automate PITR, as does the tool WAL-E. Dumps can be more compact and are portable between PostgreSQL versions and architectures, but are coarser grained snapshots of the DB state - you can't have an incremental dump in Pg.
High availability. HA isn't so much for protection against data loss as to maintain uptime. In PostgreSQL it's implemented with replication and failover. repmgr is one tool that can help you manage this, in combination with something like PgBouncer or HAProxy for connection routing.


Personally I think your minimum requirement is to use PgBarman or WAL-E to archive WAL for PITR, and do nightly dumps as additional redundancy for backup purposes.

Look into synchronous replication if you cannot afford to possibly risk losing a transaction (e.g. if you're processing financials/payments).

Investigate HA if you reach the point where downtime becomes unacceptable.