DEV Community: Calvin Torra

Why Most Startups Waste 6 Months Before Writing a Single Line of Code

Calvin Torra — Mon, 05 May 2025 11:48:24 +0000

At the pre-seed stage, startups often waste months in the planning phase, locked in cycles of research, theoretical validation, and endless brainstorming. This delays product development, leaving founders with nothing to show but a refined idea.

This “thinking time” does more harm than good.

Planning is Overrated

Many startups get bogged down in refining their ideas, waiting for the perfect MVP before they even begin building. It's easy to mistake planning for progress. The reality is that the more time you spend planning, the longer it will take to actually build.

Waiting for perfection before launching leads to an endless cycle of revisions, and you end up spending months without having a single line of code to show for it. The focus should be on speed and iteration, not perfection.

Instead of perfecting every detail before launch, get a simple version of the product out there. A basic version that solves the core problem will teach you more than weeks of planning. The sooner you start building, the sooner you can test your assumptions and refine the product based on real user feedback.

Don't Overthink Customer Validation

Founders make the mistake of thinking they can validate their ideas with surveys, market research, and customer interviews.

While these methods can provide valuable insights, they don't offer the real-world data you need to validate your product.

People might say they want something in a survey or interview, but their actual behavior when using the product will give you far more accurate feedback.

The only real validation comes when users interact with your product. Build something simple and get it into their hands quickly.

By shipping early, you start gathering the kind of feedback that drives real progress.

Avoid Over-Engineering Early

It's tempting to add features, make everything scalable, and optimize the product from the get-go, but this over-engineering will only slow you down.

At the pre-seed stage, the focus should be on solving the core problem, not on making everything perfect. Building unnecessary features or trying to scale too early can delay progress and waste valuable resources.

Instead, focus on building the simplest product that solves the core problem. Keep things lean, functional, and focused on what really matters. Once you've validated the core product with real users, you can begin to iterate and add features as needed. Keep the complexity to a minimum early on—this way, you can move faster, learn faster, and build a stronger foundation for the product.

How to Apply This in Practice

Stop over-planning: Get something functional out the door as quickly as possible. Perfection isn't necessary at this stage—just something users can interact with.

Test assumptions with real users: Build the product and let people use it. Gather feedback from actual usage, not just hypothetical responses.

Focus on core functionality: Build the simplest version that addresses the primary problem. Don't worry about extra features until the core product is validated.

Move fast, but stay lean: Avoid adding unnecessary complexity early. Focus on learning and iterating, not scaling or perfecting the product.

The biggest mistake most pre-seed startups make is wasting time on planning, research, and perfecting their ideas before building. The key to success at this stage is moving quickly, building a simple MVP, and getting it into the hands of real users. It's only by testing, iterating, and learning from actual product usage that you can refine your offering and get closer to product-market fit.

Start building now. Don't wait for perfection—build, learn, and iterate. The faster you get started, the faster you can start making progress.

Want to talk through your idea and see what's actually buildable in the next 30 days? Grab a 30-min slot. No fluff. Just clarity.

The MVP Blueprint - How Non-Technical Founders Can Ship Faster

Calvin Torra — Mon, 05 May 2025 11:43:40 +0000

Most pre-seed startups don't die from bad ideas - they bleed out while trying to build the "perfect" version of them. If you're a non-technical founder, it's easy to fall into the trap of chasing pixel-perfect UIs, overengineered backends, or vague roadmaps written by mercenary freelancers. But if your goal is to raise, not scale, you need to ship something fast, tight, and investor-legible.

Speed ≠ Sloppiness

Shipping fast doesn't mean building trash. It means cutting ruthlessly. A proper MVP is not "the first version of your final product" - it's the smallest product that proves your key hypothesis to investors and early users. That's it. Nothing more.

What you need is momentum, signal, and something demoable that doesn't fall apart when a VC asks, “So what happens after 50 users?”

What Non-Technical Founders Get Wrong

They don't define success up front.
If your MVP doesn't have a clear success condition - X signups, Y usage, Z revenue - you're building in a fog.
They trust the wrong devs.
Not all developers can build MVPs. You don't need a perfectionist who wants to reinvent auth from scratch. You need someone who can prioritize speed and clarity, and still leave you with something maintainable.
They scope to impress peers, not investors.
No one cares if you have a social feed or dark mode. Can your product solve a real problem and show traction? That's what closes your next round.

My Blueprint (That I've Used to Ship MVPs in 2–6 Weeks)

Rapid Product Definition.
One call. We define your core user, key outcome, and must-have features. No fluff. No endless roadmapping.
Tech Stack Built for Speed + Clarity.
I use battle-tested, boring tools that get you to market fast: 99% of the time AWS, Clean codebases. Easy handoff later.
Traction-First Mentality.
Every feature has a reason. If it doesn't move a metric or tell a story, it's out. We focus on proving something an investor can believe in.
Demo-Ready in Weeks.
You'll have a working, hosted MVP you can walk through in a pitch - plus the confidence that it won't collapse under first contact.

Why This Matters

You don't get a second chance to show that you can execute. You're not being judged on the elegance of your code - you're being judged on whether you can turn vision into momentum.

I've helped founders go from idea to MVP to seed round with no tech background, no team, and no time. If you've got the vision, I'll build the bridge between here and your next raise.

Want to talk through your idea and see what's actually buildable in the next 30 days? Grab a 30-min slot. No fluff. Just clarity.

What's the relationship between Free Memory, Active Memory & Freeable Memory In AWS RDS?

Calvin Torra — Tue, 04 Mar 2025 13:25:14 +0000

6 actionable fixes that lower costs and make your database faster today.

When people start digging into AWS RDS monitoring, there's usually questions around these three metrics. What do they mean and how should we be using them?

TL;DR

Free Memory: Unused RAM at the OS level.
Active Memory: Memory actively in use by processes.
Freeable Memory: Memory that can be reclaimed (includes cache and buffers).

Breaking It Down

Free Memory: This is just unused RAM. If it’s high, your instance might be over provisioned. If it’s low, it doesn't necessarily mean a problem - it could just mean the memory is being used efficiently.

Active Memory: This is what’s actually being used by running processes. It gives you a sense of how much memory your DB engine and other processes are consuming in real-time.

Freeable Memory: This one is one to watch more closely. It includes both free memory and memory used for caching that can be reclaimed. Low freeable memory means your instance is tight on RAM, and you might start seeing performance issues.

Why Does This Matter

If Free Memory is low but Freeable Memory is high, you’re fine - the system is just using RAM efficiently for caching.

If both are low, you might be headed for trouble.

Queries could slow down, and you might need a bigger instance.

If Active Memory is way below the instance’s total RAM, you could be overpaying for capacity you don’t need.

What to Do About It

Enable Enhanced Monitoring for better visibility.
Watch trends, not just single snapshots.
Upgrade your instance if Freeable Memory stays low over time.

Bottom line: Free Memory isn’t the whole picture - pay closer attention to Freeable Memory instead.

6 actionable fixes that lower costs and make your database faster today.

RDS Endpoint Name Format

Calvin Torra — Tue, 04 Mar 2025 13:23:41 +0000

6 actionable fixes that lower costs and make your database faster today.

TL;DR

In AWS RDS, the endpoint format is my-db-name.AWSIDENTIFIER.region.rds.amazonaws.com

AWSIDENTIFIER is unique. It's an identifier generated by AWS specific to your AWS account and region.

It stays consistent across all RDS instances within the same account and region.

Endpoint Structure: An RDS endpoint typically follows the pattern my-db-name.AWSIDENTIFIER.region.rds.amazonaws.com. Here, my-db-name is the database instance identifier, AWSIDENTIFIER is a unique alphanumeric string and region is... region.
Unique Identifier (AWSIDENTIFIER): This segment is an identifier generated by AWS. It's unique to each AWS account within a specific region and remains the same for all RDS instances under that account in that region. They don't share the algorithm publicly.

Trade-offs & Gotchas

Predictability: You can't predict or choose the AWSIDENTIFIER value before creating an RDS instance. But, once an instance is created in a region, this identifier becomes known and remains the same for all future instances in that account and region.
Consistency: If you delete an RDS instance and later create a new one with the same name in the same account and region, the endpoint will have the same AWSIDENTIFIER identifier. This helps with maintaining stable connection strings.

Recommendations

Even if you can't predict the AWSIDENTIFIER identifier beforehand, you can programmatically get endpoint details after creating an instance using AWS SDKs or CLI tools.

To simplify data recovery or architecture changes, it could be worth renaming your RDS instance the same as the original instance, this means you don't need to update your application with a new endpoint 🤷🏽‍♂️

6 actionable fixes that lower costs and make your database faster today.

Create an API to get data from your DynamoDB Database using CDK

Calvin Torra — Fri, 18 Oct 2024 15:20:59 +0000

Viewing console.log's of a lambda function

Calvin Torra — Thu, 17 Oct 2024 11:15:58 +0000

A lot of developers are used to running their code and seeing console.log locally, but when deploying or debugging a lambda function to AWS, it's not immediately obvious where these debug logs are printed.

Head over to the AWS console and locate the Lambda in question.

Open up the Monitor tab under the function overview panel, then View CloudWatch logs.

This opens up a new service page with a list of requests, sometimes grouped, to this lambda function.

Choosing the most recent log makes sense here. You'll get a list of data with arrows that you can click to drop down.

This is where you can find the console.log() statements.

You can also use a useful logger with Lumigo.io but that is another service all together.

How to build an API with Lambdas, API Gateway and deploy with AWS CDK

Calvin Torra — Fri, 11 Oct 2024 19:24:12 +0000

Creating a new AWS CDK Project and deploying a Lambda Function

Calvin Torra — Mon, 07 Oct 2024 17:04:32 +0000

Build A Responsive Currency Converter app with React.js - Tutorial From Scratch

Calvin Torra — Wed, 01 Feb 2023 16:17:03 +0000

Build a Modern Real Estate React.js App | Next.js Website Tutorial

Calvin Torra — Tue, 24 Jan 2023 18:36:11 +0000

How to handle multiple queries with React-Query

Calvin Torra — Sat, 07 Jan 2023 07:56:19 +0000

There are two ways to handle multiple queries with React Query.

Method 1: Call useQuery Twice

The simplest method is just to call useQuery twice but re-assign the data variable that we're destructuring. They can't both be called data.

const { data: userData } = useQuery("users", fetchUsers);
const { data: postData } = useQuery("posts", fetchPosts);

Method 2: useQueries

There is also useQueries which is perfect for this situation. It returns an array of queries. We can get access to each one using array destructuring.

const [posts, users] = useQueries([
    { queryKey: ["posts"], queryFn: fetchPosts },
    { queryKey: ["users"], queryFn: fetchUsers }
  ]);

The queries that are returned from useQueries also contains the usual suspects like isLoading isError etc.

const [posts, users] = useQueries([
    { queryKey: ["posts"], queryFn: fetchPosts },
    { queryKey: ["users"], queryFn: fetchUsers }
  ]);

const { data, isLoading } = posts;

There are also situations where you may want to wait for everything to finish before rendering any data. In that case, we can check if any / some of the queries are still in their loading state (isLoading comes from the useQuery hook).

  const results = useQueries([
    { queryKey: ["posts"], queryFn: fetchPosts },
    { queryKey: ["users"], queryFn: fetchUsers }
  ]);

  const isLoading = results.some((query) => query.isLoading);

  return { isLoading, results };

Within our component, we only need to pull in 1 isLoading value and handle that case until ALL of the results are ready.

How do I get the data from useQuery in onSuccess callback?

Calvin Torra — Thu, 05 Jan 2023 07:20:39 +0000

Join my newsletter Here:

Once a week, I share my best finds on:

AWS
JavaScript
Web Scraping
Indie Hacking

There was a bit of confusion on how to get data back from useQuery hook. The developer asking this question thought that the onSuccess key was how you finally got your data from useQuery.

The onSuccess and onError are callback functions that are called after a fetch has succeeded or failed.

They're optional and useful. They're called and passed the data that has been retrieved from the useQuery call so that you can trigger side effects, such as modal popups or something similar with your new data.

const { data } = useQuery("posts", fetchPosts, {
  onSuccess: (data) => console.table(data.data),
  onError: (error) => console.log(error.message)
});

/*
  Updating the name from data to dataRetrieved, makes it more clear.
  We're usually expecting the { data }
*/

const { data } = useQuery("posts", fetchPosts, {
  onSuccess: (dataRetrieved) => console.table(dataRetrieved.data),
  onError: (error) => console.log(error.message)
});

The data that you are expecting is { data }, this is the variable that you are probably looking to return after a successful fetch in most cases, not dataRetrieved.

After Post Requests

Similarly, after a post request, we want to invalidate the key, The invalidation of the key tells React Query to re-fetch and update the data.

So after a post request to our API (updating the database), we'd normally want that new data to be shown. If the key is not invalidated, we'll see old data rather than new data.

To do this we need to pass onSuccess the queryClient as well as set invalidateQueries with the key we want to update.

// Post data to our API
const poster = (id) => {
  return axios.post(`https://yourapi.com/posts`, id);
};

// Tell React Query to invalidate the posts key
// and fetch the new data again to see our changes.
export const useAddPosts = () => {
  const queryClient = useQueryClient();
  return useMutation(poster, {
    onSuccess: () => {
      queryClient.invalidateQueries("posts");
    }
  });
};

Join my newsletter Here:

Once a week, I share my best finds on:

AWS
JavaScript
Web Scraping
Indie Hacking